I am working on a restaurant web portal which will send periodic emails to the registered users such as changes in menu, discounts and offers, birthday wishes etc.
Here is how I am doing it-
I create a JSP page with the HTML formatting. This page accepts certain parameters that will customize the page.
The MailDaemon scans the db and upon a certain trigger will make a GET request to the JSP.
The returned JSP represents the final mail content which is then sent using the JavaMail API.
My questions are these -
Do I really need to make a GET request? Or can I obtain the JSP result directly in my Daemon class?
Does my approach have any drawbacks? Any better solutions (architecturally speaking)
Any other templating solutions for the job?
It's possible to buffer a response from your JSP using javax.servlet.RequestDispatcher#include by wrapping original response in javax.servlet.ServletResponseWrapper (in case your MailDaemon is a servlet)
Your approach is OK. Though it'll be easier to leverage another templating engine.
Apache Velocity or FreeMarker. These two are not tied to web, so you can easily use them without servlet container.
If I understand correctly, you're using the JSP as a templating engine to generate the body of an HTML email. If you want to keep using JSPs for that, I don't think there's a better solution than making a GET request to get the generated HTML.
But you could also use an embeddable templating engine like Velocity or FreeMarker to generate the HTML to a String, directly from the mail daemon.
Related
I was browsing the typo3 core Forms framework documentation but with no relevant answer to my requirements which are:
The form has to be displayed in a frontend overlay.
The filling process involves multiple steps where the user would be able to go back and forth.
The form fields must still be editable by a redactor.
I'm not sure about how the form framework behaves, so far I remember I think that multiple steps are configurable from the backend module but I don't know if it sends request to the controller after each step or if it sends everything only on submit.
I have an idea about how to implement it though, it's based on this question how to get a typo3 form framework html via ajax. Which would just let me provide the whole html content to the frontender and let him split the whole form into steps. The separation would be based on the addition of some special tags via the editor that would surround the fields you want in each step.
What do you think about that approach?
The form framework proceeds each form step seperately. So without developing your own form runtime, you have to keep proceeding every step seperate.
I see two possibilities:
1. Send each form step from frontend to the form controller and replace the response (html form) in the frontend.
That is the fast and easy way, as you use the existing form runtime.
Prepare a page which returns the rendered form as html
Fetch this page by JavaScript
Send the form data back to the given form action
The form controller proceeds the form with all its validators, rules and finishers and returns the next step, previous step, the current step with existing errors or the finishers response on success
Replace your form in the frontend with the already rendered html response of the form framework
The advantage of this way: Less effort and you can rely on the already existing validators, as you get an already validated response.
The disadvantage of this way --> it is more difficult to implement frontend validation, as you have a mix between frontend and server side validation.
2. Make the form framework kind of headless and work json based
In my opinion the better approach, but with a lot more effort to take.
You have to extend / overwrite the controller and the form runtime. This allows you more flexibility in handling the form by JavaScript and e.g. return the errors in a json object. It makes life easier when you want the form render and handle with a JS framework like react or vue.
To your question:
What do you think about that approach?
If I got it right, you want to keep ONE form step in the backend, but let the editor divide this form step into multiple steps by adding tags? You can try, but I don't see any real advantage in keeping the original form steps and proceed every step by sending the step to the controller and handle the response (like mentioned in 1.)
Summary:
In the past, I was thinking a lot about handling forms by JavaScript and came to the conclusion:
Keep the form framework's behaviour completely untouched with server side processing or make it frontend driven, with an own runtime. All mixtures between client and server side rendering will sooner or later run into bigger problems or at least a high effort. The form framework is pretty complex with a lot of possibilities, hook driven behaviour, etc. From my experience, you have to know it pretty good to develop without loosing control. In smaller projects with just one or two basic forms, I would try to avoid special cases with lots of JS. In bigger projects (with more budget), I would definitely go with my second mentioned approach (currently, I'm developing vue.js based rendering and handling of the form frontend). But these are just my five cents...
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 am trying to create a RESTful web service that accepts JSON arguments and gives out a JSON response.
What I want is to accept HTTP requests made to my URL endpoint.
Something like,
POST /the/endpoint HTTP/1.1
Host: mywebsite.com
{"name":"yourname", "department":"your_department"}
Do a DB read at the backend and give relevant parameters like, say Manager name, salary etc as a JSON object, as the response.
What's the best way to go about it? I was thinking of using Java servlets for this? Is there a better way?
PS - I am just getting started so detailed answers or links to tutorials as to how to implement it would be much appreciated.
Thanks.
Yes you can easily do this with Servlets and some Json Libs for Marshalling /unmarshalling the Json Object to Java Object.
You can make use of Json libs like
Jackson ,
Gson etc
But you must know that REST application doesnt end with just handling the request and response , but it needs to take care of other non-functional requirements like
Authentication
Authorization
Security etc
Building this from a scratch from a Servlet is overkill and waste of time when there are ready made frameworks that these things for you
My favorite is Spring MVC 3.0
Check their project site for more details
Just to show you how easy to set up one in Spring MVC , check this below tutorial
Spring 3 REST Tutorial
Pls rate the post if it helps , Cheers.
If you want to go with Java, I suggest that you take a look at JAX-RS... And since REST is a complex topic, here is a url with tons of informations on it. http://code.google.com/p/implementing-rest/
As a complete beginner, I believe the best way to implement a (nearly) RESTful API without having to read a lot is simply to implement the API just using HTML pages and HTML forms with the back-end processing to handle them.
The rules are:
Use <a> tags to provide links to related resources. (navigation)
Use <form> tags to initiate any kind of processing operation on the server. (actions)
You can then make it properly RESTful by using progressive enhancement to add Javascript AJAX requests that perform PUT, PATCH, and DELETE instead of using POST for those three (of course, keeping POST for creating resources where the client doesn't know the resultant URI).
You can then click around and test the API in a web browser! Tools like Selenium can automate this.
If you need to provide JSON, this can be added after the API has been designed and tested, although libraries exist to process HTML or XHTML responses too, so JSON isn't necessarily required for machine readability.
if you are using php with symfony try:https://github.com/FriendsOfSymfony/FOSRestBundle this lets you create a real REST full servicer very quick.
Vogella made my day very easy when i started Web services with an super example here with eclipse screen shots ..Have a look here.
I understand that Scalatra is a lightweight framework. However, I'm wondering if there are any tricks for managing small amounts of state. I have a form with a textarea and a few checkboxes. For example, suppose the textarea contains a math equation and the checkboxes some additional options. When I submit (method=POST), I would like to display a result beneath the form, but maintain the same options (same text in the textarea, same checkboxes checked).
Is there a good way to accomplish this? Or do I need to manually set the values when generating the HTML? I'm presently generating HTML using Jade.
Do it server side with a resource returning JSON, and call it dynamically using JavaScript XHR.
No need of state! Go away Evil State!
EDIT
~A bit more explanation~
You create a webservice that take computation parameter as input (using ?= in url with GET, or better using JSON payload with POST), then the service do the computation and return a JSON representation of the result
You call that scalatra webservice using AJAX from your web application and you update the content of the webpage using the JSON result returned by the web server
If you don't already know much about AJAX, read tutorials and I think you will understand better what I mean. You can too search for example of Scalatra resource that return JSON representation (using lift-json i.e.)
As a side note, you can take a look at Bowler: http://www.bowlerframework.org
which make REST development on scalatra easier.
I am working on a new web project based on Spring MVC 3. Now trying to decide to use spring form tags or not. Personally I don't like to use any tags other than HTML and JSP. It takes time to learn them and it is so hard to understand how they are rendered and the error msgs when they occur. So are there any outstanding advantages to use them? Thank you!
The Spring MVC form tags are very basic indeed, but they're better than nothing. If you're trying to render HTML forms, with submissions, error messages, and resubmissions, they take a lot of the annoyance away (especially for <select> fields, which are a huge pain to handle otherwise).
For anything more complex, they're pretty useless, but for forms, I see no reason to not use them.
Another benefit of spring tags is that when you make a mistake and you write the name of a property which doesn't exist in the object to populate it gives you an error, so you can easily find-out that you have to correct the name of the property in the path attribute of the tag.
The benefit of using the spring form tags is that you will get consistent data binding and error handling across your entire website. I would recommend wrapping the spring form tags in your own tags - this will allow you to easily swap in your own implementations at a later date if you find the spring tags lacking functionality you need.