We are using a traditional CMS that also offers API (Rest & GraphQL) to expose content on top of page builder capabilities, I want to understand:
How to know if my traditional CMS is also a true Headless CMS?
Can a headless CMS offer Page management capability or it can only
create the content pieces that can be tagged & exposed via API to
multiple channels?
If that is the case, then doesn't my front-end logic needs to take
care of a lot of things while rendering the page to understand which
content will go first & which one last?
Wouldn't this create a tight coupling between CMS & Front End (be
it in the form of taxonomy)?
Is there any real advantage for Content authors in headless CMS as I
believe they will lose the drag & drop / WYSWYG features that is common
in traditional CMS?
Thanks
Your CMS is truly headless only if the content is completely separated from the context it is displayed in, that is, you should be able to change the destination of where the content goes, and have your front end determine where and how to layout the content. If your CMS controls or entirely owns this, it is no longer headless. If you're using contentful, this can be made easier by their JSON responses that come in a very structured order. In this case you are providing some context, but it is not anywhere near a dependency. These responses from the API are editable. So you can easily change this dependent on the destination of the content.
Yes it can, Headless CMS's provide enough metadata (ID's Slugs etc.) for you to create variable routing on your web application. Contentful also has the capability to attach SEO information with new content types. Keep in mind, a Page can be a content type that holds other content types. In this sense, your pages should be able to accept generic component objects, which will render a specific layout for each. Then that layout is backed with content from contentful.
As far as understanding which goes first, this can be inferred by the structured JSON response that comes from contentful or other headless CMS's. So it isn't much work to layout the order of things correctly. Here is an example from their docs. If your entry is a single entry that contains other types of content, they come in the order that they appear within the headless CMS, which means editors can shift things up and down as they choose.
https://www.contentful.com/developers/docs/references/content-delivery-api/#/reference/entries/entry/get-a-single-entry/console
to put it shortly, yes. You have to do a larger amount of work on the front end to accommodate this, but there are benefits long term. Once you have a suite of content types and layouts, eventually, the editors can become autonomous.
The advantage for editors is more of a safety for developers. Because they are locked into only editing content, it is impossible for an editor to make mistakes regarding style, positioning, or responsiveness. They also do not need to learn new technologies if you decide to change the front or backed of your web application. All the editors can see is the content magically appearing on the website. If they want to change the layout of a section, they don't need to contact you for these types of changes, so long as you've implemented that layout for a component. It keeps everything uniform, and allows for teams to effectively manage releases for new content.
Related
I need to programmatically interact with a WebObjects website and extract data from the responses. The particular WebObjects site I am scraping uses component actions and stores sessions in cookies (not urls). This means that all urls look something like this:
http://example.com/WOApp/WebObjects/WOApp.woa/wo/7.0.0.0.29.1.1.1
My first questions are:
Does urls like this not completely destroy local and shared caching opportunities (cachable constraint in REST)? I imaging the only effective caching with such urls is the WebObjects server itself.
Isn't addressability broken as well? Each resource does have a unique endpoint, but it changes constantly. Furthermore (I think) that WebObjects also makes too old URLs invalid since they "time-out" after a period of time. I'm not sure whether this applies only to urls with sessions though.
Regarding the scraping I am not sure whether it's possible to extract any meaningful endpoints from the website. For example, with a normal website I would look through the HTML and extract the POST urls, then use them in my scraper by posting directly to them instead of going through the normal request-response cycle.
In this case I obviously cannot use any URLs extracted from the HTML since they are dynamically generated on each request, but I read something about being able to access WebObjects components directly if the security settings have not been set to disallow this (see https://developer.apple.com/legacy/library/documentation/LegacyTechnologies/WebObjects/WebObjects_3.5/PDF/WebObjectsDevGuide.pdf, p. 53 "Limitations on Direct requests"). I don't understand exactly how to do this though or if it's even possible.
If it's not possible what would be a good approach then? The only options I can think of is:
Using a full-blown browser client to interact with the website (e.g. WatiR or Selenium) and extract & process the HTML from their responses
Manually extracting the dynamic end-points by first request the page where they are on and then find the place in the HTML where they're located. Then use them afterwards as if they were "static".
I am interested in opinions on how to approach this scenario since I don't believe any of the solutions above are particularly good.
You've asked a number of questions, and I'll see if I can cover each in turn.
Does urls like this not completely destroy local and shared caching
opportunities (cachable constraint in REST)? I imaging the only
effective caching with such urls is the WebObjects server itself.
There is, indeed, a page cache within the WebObjects application server, and you're right to observe that these component action URLs probably thwart any other kind of caching. Additionally, even though the session ID is not present in the URL, you'd need the session ID in the cookie to re-create the same page, so having just that URL would get you a session restoration error from the application server.
Isn't addressability broken as well? Each resource does have a unique
endpoint, but it changes constantly.
Well, yes, on the face of it this is true. You've given a component action URL as an example, and they're tied to the session.
Furthermore (I think) that
WebObjects also makes too old URLs invalid since they "time-out" after
a period of time. I'm not sure whether this applies only to urls with
sessions though.
Again, all true. Component action URLs generate sessions, and sessions time out.
At this point, let me take a quick diversion. I'm assuming you're not the owner of the WebObjects application—you're talking about having to scrape a WebObjects app, and you've identified some ways in which this particular app doesn't conform to REST principles. You're completely right—a fully component-action-based WebObjects application won't be RESTful. WebObjects pre-dates REST by a few years. Having said that, there are ways in which a WebObjects application can be completely RESTful:
Using session-less direct actions gives a degree of REST-like behaviour, and would certainly solve the problems you identify with caching, addressability and expiry.
Using the ERRest framework to create a 100% RESTful application.
Of course, none of this will help you if you're just trying to scrape a legacy application.
Regarding the scraping I am not sure whether it's possible to extract
any meaningful endpoints from the website. For example, with a normal
website I would look through the HTML and extract the POST urls, then
use them in my scraper by posting directly to them instead of going
through the normal request-response cycle.
Again, if it's a fully component action-based application, you're right—all those URLs will be dynamically generated and useless to you.
In this case I obviously cannot use any URLs extracted from the HTML
since they are dynamically generated on each request, but I read
something about being able to access WebObjects components directly if
the security settings have not been set to disallow this…
That's talking about getting a component to render directly from its template with some restrictions:
As you note, the application can easily prevent it from happening at all.
As mentioned on p.53, the user input and action-invocation phases of rendering the component are skipped, which probably means this approach would be limited to rendering a component that didn't have any dynamic content anyway. This might be of some very limited use to you, though you'd need to know the component names you were interested in, and they wouldn't normally be exposed anywhere.
I'm not sure you're going to find anything better than the types of high-level functional approaches you've already suggested above, such as automating at the browser level with Selenium. If what you need is REST-style direct addressability of resources within the application, you're not going to get that unless you can re-write the application to use direct actions or ERRest where you need them.
A little late, but could help.
I use the Apache's mod_ext_filter (little modified) to pre/post filter the requests/responses from our WebObjects application. The filter calls PHP scripts and can read the dynamical hyperrefs and other things from the HTML pages. The scripts can also modify the HTTP requests, so we can programatically add/remove parameters from the request to implement new workflows in front of the legacy app and cleanup the requests before they will reach WebObjects. It is also possible to handle an additional database within the scripts and store some things over multiple requests.
So you can get the dynamically created links (maybe a button's name or HTML form destination) and can recognize these names within the request.
It is also possible to "remote control" such applications with little scripts like "click on the third button on the page". The only thing you need is a DOM parser to get the structure of the HTML pages and then rebuild the actions which the browser would do (i.e. create the HTTP request manually and send it as POST to the extracted form destination href). The only problem is the Javascript code, which we analyze and reprogram within PHP (i.e. enable/disable input elements, so they will not be transmitted within the requests)
There were some problems within the WebObjects Adapter Module for Apache. It still uses Content-Length within the HTTP header, which you cannot change in mod_ext_filter. If you change the HTML or the parameters within the request, the length of the content will not longer match. But it is possible to change that.
Theoretically it could also be possible to control such an closed-source legacy application from a new UI on a tablet or smartphone, which delegates the user interaction to the backend WebObjects app.
The scripts depends on the page structure, so if your WebObjects app will be changed, you have to correct some things in the scripts (i.e. third button could be now the fourth button).
It should also be possible to add a Restful interface in front of the application and query the data from the legacy app by the filter scripts.
I have an idea to add a edit-layer to website as a Plack middleware.
Explanation: let's say, we create a website, based on some framework and templates and CSS (requesting it like /some/page). Now we could create a middleware so that every request to pages starting with adm (like /adm/some/page) shows the same page, but adds a layer for content editing. So we could easily look and use the page as visitors do, but with double-click on block-level element we could modify or add content. So middleware should bind certain block-elements with certain events (double-click) and set handlers too (with some Javascript library).
For now it is just an idea and i have not seen such approach in any CMS. I am looking for hints and ideas and examples, how to start and implement such system. I hope, there is already done something like that.
You could do it, but I don't think you want to do this. My understanding is that Plack::Middleware's are supposed to be generic, and implementing a CMS as a plack middleware limits its re-usability, and its out of place, there is no inherent connection between a middleware and a CMS.
See these as examples Plack::Middleware::OAuth, Plack::Middleware::Debug, Plack::Middleware::iPhone, Plack::Middleware::Image::Scale, Plack::Middleware::HTMLMinify
It would be trivial to add a middleware filter to insert a form in your html based on /adm/ or /admin/ or whatever ... and mapping the url to the dispatch would highly depend on the underlying CMS model/view/controller framework, which is why frameworks such as Catalyst, Mojolicious and other already provide this feature
See http://advent.plackperl.org/2009/12/day-23-write-your-own-middleware.html
Basically, I think this is a job for a view/controller of your application, a plugin, not a wrapper for your application (middleware)
I know my explanation is lacking but hopefully you catch my drift
I'm quite new to Seam and am working on a relatively large project at work. The application is quite complicated in that there's a lot going on a single page at any time. I'm trying to figure out how to structure this and would like some feedback.
A good example to base this on would be Facebook (or a similar social media app). Facebook has a ton of stuff going on the screen. If all that logic were in a single view and backing bean, the files would be monolithic in size.
The way I see it is you'd have different components. For example, in Facebook, there'd be a component that handles showing your friends or friends in common with another person, there'd be another component handling invitations, suggestions, etc, etc.
All this is separate functionality being displayed on a single page however, in some cases, although being separate components, they're related at the end of the end. For example, if I click something in the main screen (i.e. not the elements in the sidebars) that generates an ajax request, a component in the sidebar might need to be updated automatically or rerendered.
Further than just sidebar components, there might be multiple disparate elements in the main area of a page (for example, a tabbed area where each panel could, in actuality be a separate or a separate view of the page).
It would be ugly if I had to handle everything in a single backing bean or something similar. It makes sense to me that each of these disparate elements have their own controllers (backing beans?) and what not. If I do an action in component x, it's bean could fire an event that could be listened to from component y's bean (thus causing component y to be rerendered).
Any ideas or resources I could look at?
Seam certainly allows division of pages into multiple fragments with separate backing components. They can be quite independent but can also interact.
To learn it, start with the Seam tutorial at JBoss and the book Seam in Action.
For the Ajax interaction you're looking for, you might also want to look at the RichFaces Developer Guide.
I've been thinking about this recently and I don't know a really nice and tidy way of creating a mobile version of an existing or new MVC2 website/app.
I think the easiest way would be to just use a different stylesheet depending on whether a mobile was detected but sometime you need to change the view content too if you have massive inline images everywhere or for other reasons.
What is a good approach for this? Is there a way of theming fairly easily in MVC2?
Well MVC is just your server-side technology, what you should ask to yourself is "what is the best practice to create a mobile web site, regardless of the server side tech".
In my opinion, creating a well-formed and semantic (x)html is the first step. As you say, the most logical thing to do is create different style sheets for different media types, and you're right.
As for the problems you mention, like inline images, consider this: are those images content or presentation?
In the first case, they should be present even in the mobile version.
In the latter, they are defined in the style sheet, so you can simply avoid them in the mobile css.
The only exception I can think of is when you want to provide different functionality on mobile, or if you're forced to, i.e. on pages that rely heavily on JS and those scripts wouldn't run on mobile browsers. In this case, you might want to create different versions of those pages and serve the appropriate version based on the user agent.
Check the source code for NerdDrinner. They've implementated a MobileCapableWebFormViewEngine class which inherits from base WebFormViewEngine class. The MobileCapableWebFormViewEngine uses the HTTPContext to decide which View to render in the client. This'll make more sense when you see the source code
This seems like an elementary question, but after a lot of searching around I can't seem to find a straightforward explanation:
If I'm building a web application that is going to be accessed largely through a web browser, but that will also support some API requests in a RESTful way, should there be a large degree of separation between the two?
On one hand, it seems a large amount of the functionality is the same, with identical data presented in different views (HTML vs. XML/JSON). But on the other hand, there are certain things I need to present to the browser that doesn't quite fit a RESTful approach: how to get an empty form to create a new instance of a resource and how to get a pre-populated form to edit an existing resource.
Should these two different methods of accessing the system by funneled through different controllers? Different methods in the same controller? The exact same methods with a switch for view type?
Your core controllers don't have to change, but that doesn't mean you can't have some extra ones solely to support you UI. For example, both of the Form examples you have can be unique to the Web API. Your entry URIs can certainly have links to those pages for both the machine and user interface, just don't expect the machine users to actually use them.
Also, if your machine clients are simply XML/JSON, then those representations don't need those links at all to the forms, since they'll not use them, and they don't "work" in JSON/XML anyway. You can manage that through Content negotiation.