I completed the StockWatcher basic gwt tutorial, and read several pages of documentation but I can't find the solution for a very simple thing.
What if my stock was a "real" object, such as an invoice, with dozens of fields to be entered by hand?b
I suppose I have to write a panel with many text boxes, and on the 'OK' button click, retrieve each textbox value in a awful way:
codeTb.getText();
year.getText();
customerTb.getText();
...
Then build a POJO-DTO and send through the RPC wire.
Really, isn't there a more simple way?
I think about a concept of "Form" in Gwt. Sorry, maybe I didn't find it in the doc, yet.
GWT has what are called Editors. With Editors you can bind Widgets to a DTO and it's fields, so you don't have to do the getText or setText yourself. It's not totaly trivial to use, but you can find more details in the GWT documentation: http://code.google.com/webtoolkit/doc/latest/DevGuideUiEditors.html
What you need is a FormPanel. Take a look here http://google-web-toolkit.googlecode.com/svn/javadoc/1.6/com/google/gwt/user/client/ui/FormPanel.html
Related
I could not find a wicket tag like wicket:include? Can anyone suggest me anything? I want to include/inject raw source into html files? If there is no such utility, any suggestions to develop it?
update
i am looking for sth like jsp:include. this inclusion is expected to be handled on the server side.
To do this, you'll need to implement your own IComponentResolver.
This blog article shows an example somewhat resembling what you're after.
Is it raw markup that you want to include, or Wicket content?
If it's raw markup, even a simple Label can do that for you. If you call setEscapeModelStrings( false), the string value of the model will be copied straight in the markup. (Watch out for potential XSS attacks though.)
"Including" Wicket markup is done via Panels (or occasionally Fragments)
Update: If you add more detail about the actual problem you need to solve, there's a good chance that we can find a more "wickety" solution, after all, JSP and Wicket are two different worlds and the mindset of one doesn't work very well in the other.
I am almost at the end of my rope trying to style my Zend form using decorators. Previously to avoid these issues I would create a form script extending zend_form, add whatever validators, labels, etc I needed then retrieved the element from my view script using $form->getElement('my_form_element');
that way I could wrap whatever css tags I wanted around the element. I thought I should learn how to use the built in decorators, but I'm starting to feel like it's a waste of my time. My old way seems easier, is there some reason I am not seeing that makes using custom decorators better?
In general decorators are used to dynamically add functionality without having to touch the code's core functionality and for a better re-usage of code. In Zend_Form however, I think that the decorator system (as well as Zend_Form in general) is unintuitive and heavily over-engineered and so it does exactly the opposite of what it should do: Help the developer to create better and more intuitive code faster.
In my opinion the usage of Zend_Form_Decorator makes only sense in the case where you have some extended logic that you plan to reuse throughout your project on multiple and different types of elements.
Let me give you two examples:
You want to add a tooltip icon next to an arbitrary form element with a nice icon and a fancy JavaScript hover box.
An element should be validated directly upon entering data by posting an AJAX request and adding either a green check mark on success or a red cross icon on failure next to the element.
With the decorator you can now separate the logic of the added functionality from that of the underlying element and so you can use the same code to add the tooltip and/or the live validation feature to a textbox element as well as any other element simply by adding all the decorators you want to the element.
There is also a great article from Matthew Weier O'Phinney, the lead developer of Zend Framwork, that gives some background insight on the motivations for using decorators along with a lot of examples: Decorators with Zend_Form
Decorators can come in handy if you have a specific repeatable markup for your forms, for example if you want to use Bootstrap. Other than that, especially if you have a good html/css person, I would avoid them.
So I'm somewhat aware of what sfFormFilter can do, but I'm more interested in when you would use it, or why. For the most part I don't understand why I'd use form filters when I can just use the forms.
Is there a conceptual difference? Or is there a feature/functional difference in the two?
If this is mentioned in the jobeet tutorial then I've definitely missed it and someone just pointing me in that direction would be cool
sfFormFilter is the form that you see when you do php symfony doctrine:generate-admin ... and go to the list action of your new module, on the right side (depending on your admin theme).
This is the form used to filter your list. So you can edit this class if you're not happy with the generated form fields, need different widgets or change other configurations.
The example below is the form filter taken from sf_guard_permission/list:
I've generated the backend of my application, and am now just 'jazzing' the forms up (adding correct labels, validation rules etc).
One thing I'd like to do is add a map (Google) which updates the marker as an address is entered into the form, then allows the user to drag it to correct the lat/lng should it be a little off.
My question is, how can I customise the output of the form - I've read the docs (1.0,1.1,1.2 also) and it all seems very confusing. Customising forms not generated with the admin generator I know how to do using renderRow(); etc; but finding a way to add a little bit of HTML to the forms is making my eyes hurt! There's so much out of date stuff on the web regarding Symfony it's hard to know what to trust!
If anyone can point me in the right direction that'd be great.
Best Regards,
Rich
Maybe you can start by looking at this plugin : http://www.symfony-project.org/plugins/sfEasyGMapPlugin .
For your question, customizing the forms can be done by creating your own widgets and using them as default widgets.
You may want to read this page : http://www.symfony-project.org/more-with-symfony/1_4/en/05-Custom-Widgets-and-Validators .
I am looking for a nice framework for developing a GUI builder Application. We have an application where 100Os of custom data entry forms and their print formats are required and each client will need some modifications on these. We have a developed a product using java based open source templatnig frameworks so that the layout and field definition are stored in database and rendered dynamically to the user. We also have an appication to design these forms but cannot do visual design.
Now I am trying to make a Visual Form Designer application for generating these forms. Can any one suggest some open source frameworks than can be used? Can I use Eclipse Visual Editor? Or is it better to develop some kind of parser for HTML using AntLR and then parse the HTML output from already existing GUI builders like Dreamweaver to get the desired output?
Thanks and Regards,
-- Kannan
Oooh, great question!
I wouldn't know any readily availble framework that you can use. Depending on your needs however, I think rolling your own shouldn't be too hard.
First of all, you probably wouldn't want to give the users too much freedom. Freedom only gives them the opportunity to mess things up and make the resultant forms hard to use. I think from your description that the fields are pre-defined, so that the user only needs to customize which fields appear on a given form, and in what order. Order can be a simple thing like top-to-bottom. Some semi-intelligent automatic layouting could be used to conserve screen space. Adding a feature to group fields together would probably also be useful, and grouping would lead to some kind of standard "group" widget.
Accepting simplified functionality like this, you don't really need the flexibility of a full gui editor. A couple of listviews, maybe a property sheet and a preview window will be enough to give your users the functionality they need.
Of course, this only holds for screen forms. Print forms may be trickier to layout, as people may want to cram as many fields as possible into very little space so the entire form can fit on a single page or something. I really don't have any suggestions for you there, but maybe a similar "simplified" approach with some intelligent auto-layouting could work.
Overall, my advice would be: Keep It Simple! (S... ;)