Re: Wicket Web Beans 1.0-rc1 Released
On 9/15/07, Zenrique Steckelberg [EMAIL PROTECTED] wrote: - allow constructor to accept models besides beans too, if possible. Me too! :-) Or is there some other way to use DetachableModels backed by JPA with WWB? (The abbreviation conjures images of a tiny but venerable local railroad company somewhere in Germany :-) ) Gabor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
On 9/17/07, Gabor Szokoli [EMAIL PROTECTED] wrote: On 9/15/07, Zenrique Steckelberg [EMAIL PROTECTED] wrote: - allow constructor to accept models besides beans too, if possible. Me too! :-) Or is there some other way to use DetachableModels backed by JPA with WWB? (The abbreviation conjures images of a tiny but venerable local railroad company somewhere in Germany :-) ) For regular models, you should be able to pass model.getObject() directly to BeanForm. AbstractDetachableModels are probably a different story. For now, you can just do model.getObject(), but then bean form will hold onto the object. I'll add detachable model support to the Feature Request list on sourceforge. Gabor
Re: Wicket Web Beans 1.0-rc1 Released
Dan Syrstad wrote:
Sounds like this may be a caching issue - I'm not sure. Can you send me
your
beanprops file directly?
-Dan
Its the following, where marca field gets it options from database, and
temperaturaArmazenagem gets them from an enum:
Produtos {
actions: incluir, gravar;
props: produtos { colspan: 3 },
action.incluir { labelImage: images/add.png },
action.gravar { labelImage: images/accept.png };
}
Produto {
actions: remover;
props: nome,
marca { fieldType :
com.everyware.fsw.web.ui.MarcaField },
temperaturaArmazenagem { default : AMBIENTE },
descricao { fieldType :
wicket.contrib.webbeans.fields.TextAreaField ;
rows : 3; cols : 40 },
action.remover { confirm : Confirma remoção do item?;
labelImage:
images/delete.png },
-id;
}
Thanks for the help!
--
View this message in context:
http://www.nabble.com/Re%3A-Wicket-Web-Beans-1.0-rc1-Released-tf4431603.html#a12701667
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
For me databinder helps cut the boilerplate code, just as WWB. I just add annotations to my domain model, and databinder does the rest. It's WWB for the database side of the app! Imagine putting both working together. I was able to create CRUD pages with the least amount of code ever. Less than that and it would need to read my mind... ;) Annotations have been a big win for Java. Many of their success stories have come out of their usage for configuration or metadata. I think that WWB may be a cantidate for using annotations instead of the beanprops file!
Re: Wicket Web Beans 1.0-rc1 Released
Although it may blur the lines between view and model, there are a number of reasons that it still could be the right direction. * centralized configuration. all view configuration is in the same file as your model code. * leverage Java syntax instead of custom DSL. easy for users to get up and going when they have autocomplete for annotation configuration. * annotations are metadata, and this configuration *is* metadata for the view layer. * configuration by exception works well with annotations. Hibernate applies the same principle. you only need to declare annotations when you want to change the default behavior. I do understand your disagreement. It's a very natural Java architecture to create abstractions and try to build to design patterns. Realistically though, there are times when it's just plain overboard. You could make the same argument that Hibernate annotations don't really belong in the model code since it's configuring the back end setup, but the beauty of annotations is that it's metadata that *any* layer has access to. I recently published a wicket/hibernate component that leverages the hibernate annotations to enforce view layer behavior (requiredness/max length). Talk about blurring the lines... I'm really impressed with your work, and just want to impart what's worked *really* well for me. Good luck with whatever direction you take. On 9/16/07, Dan Syrstad [EMAIL PROTECTED] wrote: Ryan: The WWB beanprops/metadata is a view abstraction, while your bean is a part of the model. It's my opinion that putting view-based annotations on your model is Not a Good Thing. It confuses the separation of concerns. -Dan On 9/16/07, Ryan Sonnek [EMAIL PROTECTED] wrote: For me databinder helps cut the boilerplate code, just as WWB. I just add annotations to my domain model, and databinder does the rest. It's WWB for the database side of the app! Imagine putting both working together. I was able to create CRUD pages with the least amount of code ever. Less than that and it would need to read my mind... ;) Annotations have been a big win for Java. Many of their success stories have come out of their usage for configuration or metadata. I think that WWB may be a cantidate for using annotations instead of the beanprops file!
Re: Wicket Web Beans 1.0-rc1 Released
I do control my crud list and detail pages with annotations on the model, and it works quite nice (although I can't say the panels constructing the data table and form belongs in the category pretty code, at least there isn't a lot of it). I find I often use multiple views of the same model objects though, and for the non-trivial views the annotations become less useful, although it's still nice to tie in validation and some of the simpler jpa annotations, using them for layout loses the point here. Johan Ryan Sonnek wrote: Although it may blur the lines between view and model, there are a number of reasons that it still could be the right direction. * centralized configuration. all view configuration is in the same file as your model code. * leverage Java syntax instead of custom DSL. easy for users to get up and going when they have autocomplete for annotation configuration. * annotations are metadata, and this configuration *is* metadata for the view layer. * configuration by exception works well with annotations. Hibernate applies the same principle. you only need to declare annotations when you want to change the default behavior. I do understand your disagreement. It's a very natural Java architecture to create abstractions and try to build to design patterns. Realistically though, there are times when it's just plain overboard. You could make the same argument that Hibernate annotations don't really belong in the model code since it's configuring the back end setup, but the beauty of annotations is that it's metadata that *any* layer has access to. I recently published a wicket/hibernate component that leverages the hibernate annotations to enforce view layer behavior (requiredness/max length). Talk about blurring the lines... I'm really impressed with your work, and just want to impart what's worked *really* well for me. Good luck with whatever direction you take. On 9/16/07, Dan Syrstad [EMAIL PROTECTED] wrote: Ryan: The WWB beanprops/metadata is a view abstraction, while your bean is a part of the model. It's my opinion that putting view-based annotations on your model is Not a Good Thing. It confuses the separation of concerns. -Dan On 9/16/07, Ryan Sonnek [EMAIL PROTECTED] wrote: For me databinder helps cut the boilerplate code, just as WWB. I just add annotations to my domain model, and databinder does the rest. It's WWB for the database side of the app! Imagine putting both working together. I was able to create CRUD pages with the least amount of code ever. Less than that and it would need to read my mind... ;) Annotations have been a big win for Java. Many of their success stories have come out of their usage for configuration or metadata. I think that WWB may be a cantidate for using annotations instead of the beanprops file! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
I'm really impressed with your work, and just want to impart what's worked *really* well for me. Good luck with whatever direction you take. One thing Dan could consider is to abstract enough so that both strategies could be supported. Doesn't mean he should ship annotations support, but it might help if things are set up in such a way that this can be build in. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
Ryan: One thing I started considering today after your comments was to place annotations, similar to beanprops, on the component level (e.g., Page). Currently beanprops are associated with the Page anyway, so this would be natural and provide type-safeness without bluring the view/model line. I think that Hibernate annotations suchs as required and max length are actually useful for both the model and the view. But possible annotations such as label', fieldType, and presentation order are definitely view-related. Jonathan and others have suggested a Java API and one of the consultants I have worked with actually started on this. But it needs to be finished. -Dan On 9/16/07, Eelco Hillenius [EMAIL PROTECTED] wrote: I'm really impressed with your work, and just want to impart what's worked *really* well for me. Good luck with whatever direction you take. One thing Dan could consider is to abstract enough so that both strategies could be supported. Doesn't mean he should ship annotations support, but it might help if things are set up in such a way that this can be build in. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
My suggestions to this nice compont: - allow beanprops files to be reloaded while app is running. How it stands now I have to restart the app everytime a change to beanprop file is made, it can be time consuming. - allow constructor to accept models besides beans too, if possible. I am trying to integrate WWB with databinder, and it would be useful to pass HibernateListModels to WWBs constructor. Congrats for such a nice and useful component! -- View this message in context: http://www.nabble.com/Re%3A-Wicket-Web-Beans-1.0-rc1-Released-tf4431603.html#a12690712 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
Hi Zenrique: See below... -Dan On 9/15/07, Zenrique Steckelberg [EMAIL PROTECTED] wrote: My suggestions to this nice compont: - allow beanprops files to be reloaded while app is running. How it stands now I have to restart the app everytime a change to beanprop file is made, it can be time consuming. Tomcat will reload the application automatically right now if you change beanprops, much like a class change. This takes a second or two depending on the size of your app. If your not using Tomcat, I can look at having the file reload (it is currently cached). What app server/servlet engine are you using? - allow constructor to accept models besides beans too, if possible. I am trying to integrate WWB with databinder, and it would be useful to pass HibernateListModels to WWBs constructor. I'll have to look at this. I've only had a cursory look at Databinder and I'm not quite sure when I'll have time to look in depth. I'm alway looking for help too! ;-) Congrats for such a nice and useful component! Thank you!
Re: Wicket Web Beans 1.0-rc1 Released
In the current WWB strategy, required fields are enforced in your model/DAO layer. For example, if you click your Save action, the action on your page would be invoked. This, in turn, calls your DAO or model. Often fields are conditionally required based on use case and or data conditions. We're currently using the Spring validation framework to validate required fields on the bean via the DAO. In turn, messages are returned back to the page and we add them to the Wicket feedback via the error() method. However, it would be a fairly simple matter to add a required: true parameter for times when you know that a field will always be required. I'll add this to the features requests in sourceforge. -Dan On 9/15/07, Zenrique Steckelberg [EMAIL PROTECTED] wrote: How can I make one textfield required? Couldn't find it anywhere in the docs. Besides that, I susggest you put the JavaDocs somewhere in the framwork site too. Thanks in advance! -- View this message in context: http://www.nabble.com/Re%3A-Wicket-Web-Beans-1.0-rc1-Released-tf4431603.html#a12691422 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
Hi Dan, Does your framework support drill down feature in case I have a ListBean as a property in my parent bean so that it can also generate a listview of form fields based on that properties of the Child Bean collection ? if there is also a way to customize the drill depth, it will also be nice On 9/13/07, Dan Syrstad [EMAIL PROTECTED] wrote: Hi Kent: Thank you for your kind comments! It's nice to see several months of work be useful to others. I've heard the why not Java instead of beanprops comment before. I may even do something about it ;-). Seriously, that may be offered as an alternative to the beanprops file. I chose the beanprops file for simplicity. It is declarative rather than procedural (e.g., Java). I believe that the exceptions can be specified in a more concise form than if they were to be written in Java. Plus, WWB contexts/use cases can override the default context by just specifying what's different. In fact, that's the whole WWB philosophy - programming by exception. I guess it similar to why you don't specify localization in Java - you use property files. It also why in Wicket you don't code HTML tags in Java to be output to the browser - HTML itself is more concise and direct. I actually worked with an in-house web framework that made you code the HTML tags in Java. No HTML, no JSP, just Java. It wasn't pretty ;-). -Dan Syrstad http://wicketwebbeans.sourceforge.com On 9/12/07, Kent Tong [EMAIL PROTECTED] wrote: Hi Dan, It looks very powerful! BTW, why chose to use a config file (beanprops) instead of Java code? I think doing in Java for everything other than the standard web stuff (HTML/CSS/js) is a basic principle of Wicket. -- View this message in context: http://www.nabble.com/Re%3A-Wicket-Web-Beans-1.0-rc1-Released-tf4431603.html#a12647439 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
Hi Ayodeji: See my responses below... -Dan Syrstad http://wicketwebbeans.sourceforge.com On 9/13/07, Ayodeji Aladejebi [EMAIL PROTECTED] wrote: Hi Dan, Does your framework support drill down feature in case I have a ListBean as a property in my parent bean so that it can also generate a listview of form fields based on that properties of the Child Bean collection ? Yes, it does support collections of nested beans. Please see the Invoice/InvoiceLines example in the documentation. if there is also a way to customize the drill depth, it will also be nice I'm not exactly sure what you mean by this. If you mean limit how deep the nesting goes, the answer is yes. You can alway specify whether a bean or a bean property is displayed, thus controlling how deep the nesting goes.
Re: Wicket Web Beans 1.0-rc1 Released
Hey Dan, that looks very nice! Thanks for sharing. Eelco On 9/12/07, Dan Syrstad [EMAIL PROTECTED] wrote: In response to Jonathan Locke's blog entry entitled Wicket on Wheels ( http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/6B9496DF-4AF1-455E-B94C-652709275041.html), I have released Wicket Web Beans 1.0-rc1. Although this project does not cover all of the functionality Jonathan spoke of, I believe it covers a good chunk of it. The project is hosted on Sourceforge at: http://wicketwebbeans.sourceforge.net . Summary: Wicket Web Beans (WWB) is a Wicket component toolkit for displaying and editing POJOs that conform to the JavaBeans specification. Web pages are automatically generated based on bean properties and certain conventions. If necessary, the layout, editability, and actions of these pages can be customized on an exception basis. In other words, the toolkit normally does what you'd expect, but when it doesn't, you can override its behavior. At the highest-level, WWB's BeanForm component provides rich AJAX form functionality. The Page design that the form is embedded on is left to you, this allows for customized page designs. Also, this allows multiple BeanForms may be incorporated on a single page. At your choosing, other lower-level components may be used independently of BeanForm (e.g., BeanGridPanel). WWB does not try to force you into a certain way of doing things, but BeanForm makes it very convenient to implement a bean-based form if you don't want to go to a lot of extra work. You focus on the model (beans), WWB handles the user interface. I welcome any feedback you may have. Please post feedback to the project forums at Sourceforge. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
Hi Dan, It looks very powerful! BTW, why chose to use a config file (beanprops) instead of Java code? I think doing in Java for everything other than the standard web stuff (HTML/CSS/js) is a basic principle of Wicket. -- View this message in context: http://www.nabble.com/Re%3A-Wicket-Web-Beans-1.0-rc1-Released-tf4431603.html#a12647439 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
Hi Kent: Thank you for your kind comments! It's nice to see several months of work be useful to others. I've heard the why not Java instead of beanprops comment before. I may even do something about it ;-). Seriously, that may be offered as an alternative to the beanprops file. I chose the beanprops file for simplicity. It is declarative rather than procedural (e.g., Java). I believe that the exceptions can be specified in a more concise form than if they were to be written in Java. Plus, WWB contexts/use cases can override the default context by just specifying what's different. In fact, that's the whole WWB philosophy - programming by exception. I guess it similar to why you don't specify localization in Java - you use property files. It also why in Wicket you don't code HTML tags in Java to be output to the browser - HTML itself is more concise and direct. I actually worked with an in-house web framework that made you code the HTML tags in Java. No HTML, no JSP, just Java. It wasn't pretty ;-). -Dan Syrstad http://wicketwebbeans.sourceforge.com On 9/12/07, Kent Tong [EMAIL PROTECTED] wrote: Hi Dan, It looks very powerful! BTW, why chose to use a config file (beanprops) instead of Java code? I think doing in Java for everything other than the standard web stuff (HTML/CSS/js) is a basic principle of Wicket. -- View this message in context: http://www.nabble.com/Re%3A-Wicket-Web-Beans-1.0-rc1-Released-tf4431603.html#a12647439 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
