I'm looking for a simple example of how to use GWT editor framework for editing a simple form. While there are examples out there, like this, they emit any UI related parts, such as showing how everything fits together, how form validation errors could be displayed, etc.
Lets say I wanted to create a simple form for editing a Person, with textboxes for first name, last name, and email, and validation rules to make sure all fields were filled in, showing errors in case of validation errors. How can this be done with GWT editors?
Not a complete example but have you looked at http://www.gwtproject.org/javadoc/latest/com/google/gwt/editor/ui/client/ValueBoxEditorDecorator.html for showing the error?
I think we found it hard to extends so copy and pasted it, shame and us, and changed for our needs.
It is a nice pattern though, we also encapsulated the HTML for labels, mandatory indicators, help text etc in a similar way.
Related
Hi all first an apology if this question comes as a bit vague. But i am in the process of brain storming. What i would like to achieve: In IDEs like intelliJ or Eclipse, its possible to hover on certain text and the javadocs is displayed in the tooltips. I am trying to achieve that in my JSwing application.
For instance i have a bunch of POJOs with properties like
public class Person {
/**
* Some description about the field
*/
public int age;
}
Now my "age" field will be exposed in my JSwing application. And I would like to provided contextual tooltip based on the javadoc comment when a user hovers over.
I have an idea, which is to generate javadocs and parse the html as resources. However, I would like to hear some thoughts about this approach.
e.g.
http://www.eclipseonetips.com/wp-content/uploads/2010/08/unwanted-hover-tooltip-in-eclipse.jpg
Serious answer: don't do this.
You are mixing up different kinds of information here.
Your classes and their fields are a representation of your object model in terms of ,well, code/implementation.
And there should not be such a direct connection to your UI layer that will be displaying information to the user.
Whereas: your UI deals with all kinds of UI elements. And the elements in their have "names", and "meanings", and so on (which for example, in a real world application require Internationalization!).
And you intend to mix that "code" information with your "UI elements" information; as said: don't do that.
Of course, you can think about putting reasonable tooltips on UI fields; but the information for that ... belongs to the corresponding UI element; and not to some field on some java class that happens (at some point) to be a "direct" source for that UI element.
http://pastebin.com/5Nvn1uSB this is my xhtml
http://pastebin.com/fqwiRQER this is home there is the code for menuitems that dont work...
http://pastebin.com/Phun7EKS this is registration with connection to db... but doesn't work at all not even running it
Well, I see lots of issues here. First, your description of what's happening is non-existent. It's pretty hard to help you when all you provide is code without a good description of your environment, what you expect to happen and what's actually happening.
Also, it would be helpful to know what steps you have already taken to debug your code.
That said, based on a quick read of your code, your p:commandButton is using an actionListener instead of an action which I believe is the correct attribute.
Lastly, you're using raw text fields from your web page to directly build an SQL statement. This opens you up to all kinds of code injection exploits that you probably want to avoid. You'd be better off using something like JPA as an abstraction layer that allows you to persist objects.
Basic problem
I've come across a bit of a problem while writing my own custom JSP tags to "wrap" the spring MVC form tags. I've wrapped other tags successfully but come unstuck with the select and options tags, this throws an IlleagalStateException. I've debugged the spring code and found that the options tag looks for an ancestor select tag. I'm doing this with tag files so the spring select tag is actually in a different tag file. I guess that's why it doesn't find it.
So the questions is what can I do to get round this?
Possible solutions
I've tried looking for solutions but all I've found is other people having the same problem but no solution posted. I did ponder writing my own select and options tags without using the spring tags but I don't really want to have to replicate the binding that it gives you for free. I don't mind changing to use Java classes rather than tag files but I found previously that the output won't be evaluated as a JSP so you can't output another JSP tag.
Reasons for doing this
Having thought about this for a week since first asking the question I am now clearer on what I want to achieve.
To simplify the markup needed in my JSP's
Factoring out common code (e.g. form:errors after an input or getting a translation from spring:message)
To encapsulate look and feel (CSS goes a long way but often you need to change the markup too)
To be able to build enhanced components that extend the functionallity of the spring tags (e.g. render a multi-select as a picklist or display readonly inputs as text labels)
I'll be interested to hear what people think.
Thanks
Firstly, I'm not sure what you mean by wanting control over styling. I thought you could pass-in class and id attributes to Spring tags and they were copied through (? - although I might be getting confused with Grail tags, as I've been writing Grails apps lately). Edit: plus you can style Spring generated tags by referencing an outer element. E.g. surround your form elements with a div and then style the form elements like: #myDiv input { color: red; }.
From my experience (10+ years webapp dev), its not worth the extra effort to try and future proof your app. When you choose a framework like Spring MVC you are getting a lot of stuff for free, that you would normally have to write yourself. The cost of this free stuff is a certain amount of lock-in (as you said). Spring is pretty good when it comes to this aspect - you can use as little or as much as you want and its usually pretty straight forward to engineer it out if needs be in the future.
So my take is: use the Spring tags "as is". The likelihood of you needing to remove the Spring aspect in the future is very small. As such its a worthwhile risk to "put off" if/until that scenario arrises. You have likely already spent as much time and code trying to engineer your future-proof solution as you would've spent removing the Spring tags - that it outweighs any benefit it might have provided. And add to that - you've written that code and you and/or someone else will have to maintain that code now - versus letting the Spring developers maintain the code for you.
Lastly, if you really don't want to have this lock-in and want full control over styling, then write your form elements by hand.
<select name="foo_select">
<option value="">-- select a foo type --</option>
<c:forEach var="foo" items="${fooGroups}">
<option value="${foo}">${foo}</option>
</c:forEach>
</select>
I've thought about this for a good week now and this is the shortlist:
Give up and directly use the spring tags in my JSP's
Don't use the spring tags at all and replicate their logic in my own tags
Possibly write a tag class that extends or makes use of the spring tag class
Expand the scope of my tags to wrap both the select and options tags
Given the reasons for wanting to do this (which I have now clarified in the question), I've decided to go for the last option. I wasn't keen on this originally because I thought I might end up with hundreds of parameters but it's actually not too bad. The tag files are designed for wrapping common bits of markup so this is what they're for. I've also wrapped my own tag further so there is a picklist tag which outputs my custom select tag and then writes the JS needed to initialise it.
I think this is the best of the possible solutions I've come across based on what I wanted to achieve. This is what I'm going with but I'd still be interested to hear of other peoples solutions if they think they have something better.
I'm putting together a GUI with a couple of panels.
In one panel there are components for the user to input various parameters.
In another panel, there are buttons and a place to output a plot based on data
generated using the user inputs.
I have all of the various pieces working independently now I'd just like them to
talk to each other!!
When i hit one button, I would like to take all of user inputs and combine them to
generate a data set and plot it.
Another button then to write this same data to a file.
I have code to implement all the components individually, code to write data to
a file and code to generate a plot from data. All of which works fine.
I thought that I could use the Action/ChangeEvents to take the parameters and
assign them to an ArrayList. Then use this arraylist to generate the data.
I'm finding it difficult to plan an approach to tackling this.
Currently I'm using get set methods in the event handlers to set parameter levels for
a particular instance of the array list, I would like to pass this instance into another class to generate the data but don't know how to make it accessible.
I hope I have provided enought information here. If anyone has any
thoughts on this they would be much appreciated.
I think a structured way to tackle your issue is to apply the MVC pattern. Here is what I think a seminal article about Model-View-Controller (MVC) using Java.
Java SE Application Design With MVC by Robert Eckstein,
and here is another sample code.
As for taking the parameters from one panel and pass them on to the other panel, you can use the Command Pattern. What the pattern does is basically encapsulate all the information needed for a method to perform (an instance of a class, parameters, etc.) into one Command. This Command then can be passed around in the application, simplifying the way you execute the method.
A good book about Design Patterns, by the way, that I really love is Head First Design Pattern.
EDIT:
I'd just like to add some links discussing about MVC and some other GUI architectures that I find useful:
GUI Architectures by Martin Fowler
Build your own Composite Application Block series: UI Architechtures, Patterns and WinForm Examples
MVVM vs MVP vs MVC: The differences
This seems like a good case of application of MVC pattern:
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Another good resource would be this book's second chapter:
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?ie=UTF8&qid=1334437965&sr=8-1
I am making a simple CMS just for learning purposes and I have a question how I would organize it. I have an administration section where you can add new pages, edit content etc, and I also have a public part that the user see for example the pages.
So, I have PageEJB class that has logic for adding a page, edit a page, deleting a page, finding a page etc. in other words logic from the admin section and public section is in the same class. Should I instead make a PageAdminEJB and PageEJB and separte the content?
Since you're doing it for learning purposes only, will you learn anything by having two EJBs instead of one?
I'd say: start with one, see how it grows. When it reaches critical mass (when you see it does too much), refactor it. This way you'll learn how hard/easy is to introduce a new EJB to your system. Perhaps the facade design pattern will help you then.
Based on what you wrote, it's difficult to advise decisively one way or the other.