Im a relative newcomer to GWT.
Im working on a GWT application, where I have a lot of table data that is to be displayed on a page and a redirect to a different service which happens when I click on each cell's data. Currently what is happening is that the entire HTML(with all of the cells' hyperlinks) is being created on the server side and returned as a big string which is rendered on the client side. As you can imagine, it doesnt scale well. I need to make this redirect more dynamic. Can anyone suggest how I could link the DOM elements with GWT code to make this happen?
Regards
In GWT there is Ui Binder
Declare your all ui on client side and hit the server only for the valuable data.
Browsers are better at building DOM structures by cramming big strings of HTML into innerHTML attributes than by a bunch of API calls. UiBinder naturally takes advantage of this, and the result is that the most pleasant way to build your app is also the best way to build it.
So avoid passing html through the wire.
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 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.
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'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
Anyone know of any tutorials implemented across multiple web application frameworks?
For example, I'm starting to implement GWT's Stock Watcher tutorial in Turbo Gears 2 to see how difficult it will be to do in Turbo Gears 2.
Likewise, I'll be looking for a Turbo Gears 2 tutorial to implement in GWT.
But I hate to re-create the wheel - so I was wondering if anyone was familiar with such projects and/or would be interested in helping me work on such a project.
Thanks,
--Spencer
While it is possible to combine the two frameworks, I hope to convince you not to do so.
Most web-frameworks, including Turbogears, have server-side page flow management. A page is served to the user by generating html, user interacts by clicking on links or by posting a form, the browser sends a fresh request to the server, and finally server responds with new html altogether. You AJAX'ify the page by using a js library, or the framework has some support. But, in general, transition from one view to another is done on the server side.
GWT is totally different. There is only a single HTML page in the system. Once this page is downloaded, everything happens on the browser through javascript. When the user clicks on a link, its essentially just a javascript function call. History management is done through fragment urls (the portion after the #).
These two philosophies are poles apart. So apart that I daresay GWT doesn't work well with any server-side web technology. See this discussion on GWT vis-a-vis JBPM/Struts/Spring Webflow. And see this discussion on GWT v/s JQuery.