[JBoss Seam] - Re: What is Gravel?
by david.lloydï¼ jboss.com
Gravel is a supplementary JSF component/tag library for Facelets. It should work with or without Seam (it was not designed for Seam specifically). It does not provide widget-style components like RichFaces; instead it provides more basic "structural" and utility components.
For example, there is a tag to allow standard JSF action listeners to be run at response rendering time; there is a tag for grabbing request parameters and assigning them to EL expressions (with an optional converter); there are tags for access role checking, properties file handing, reading JSF messages into collections, session management, etc.
Also there is a set of tags that are "wrappers" around standard HTML tags, but provide the advantages of components: optional rendering using the standard rendered="", the option to render the content without the tag based on EL, JSF ID management (including handling ID lookup for HTML tags that take an ID as their argument), etc.
There are action listeners that provide data-management functions like sorting and filtering, and pager support. Also there are components that are equivalent to h:dataTable and ui:repeat, but they evaluate at render-time, meaning that the state-saving and data visibility difficulties that plague these two components are eliminated.
Finally there is an (optional) alternative navigation handler that allows the developer to specify the navigation rules right in the XHTML, with the added benefit of being able to preserve JSF messages across redirects. Also an (option) alternative view handler that preserves the original GET request parameters when looking up action URLs.
Gravel was conceived out of a set of components that were developed for the jBPM web console, but were not specific to jBPM. I factored these components out and built on that. My goal was to create a component library whose main goal was not yet another widget set (how many tab controls do you really need anyway?), but instead to provide a logical set of components that are very basic functionality but yet are missing from the basic JSF component set.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053161#4053161
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053161
18Â years, 11Â months
[JBoss Seam] - Re: Seam and Adobe Flex
by livenow
Hi,
I've been working with Flash since 5.0 and building quite a few Apps (e-Learning, CRM, Transport&Logistics etc.) on it.
The approaches used by Flex and OpenLazlo have been around some time now and on the first look it seems to be a great idea using them for RIA but there are also some downsides which you should consider first:
- target audience:
if the target audience, especially the clients (OS, Hardware) involved, is not known by you, there is a good chance to run into the following problems:
*Plugin not installed, not allowed (e.g. large companies, public sector, industry)
*Crashing/Hanging Webbrowser: Flash is not canny - you pay for the user-experience in means of ram, cpu -> be aware that the gc is quite lazy and after heavily usage of Flash-Apps mem-usage is running high -> problems started at ~150mb mem and 1 hour intensiv usage.
- compatibility:
if its truly RIA you are heading for then you'll have some sort of desktop-style apps, not just small widgets embedded in plain html which leads to the following difficulties:
*no HTML in flash: don't try rendering iframes via dhtml on top of flash-objects in the circumstance that you have to display html content somewhere. so you have to stick to flash and forget about html. Sure, some things from html work - e.g. font tags, but many things won't work
*same with active-x controls of course
- authoring:
be aware that its quite painfull planning some sort of CMS within your RIA.
- text-legibility:
because flash is vector based several fonts and font-sizes are really hard to read - so its simpler to stick to the system font which makes it not so fancy again.
- accessibility:
text-2-speech readers have major problems with flash. So if you are developing for .gov or .org you should inform yourself about the legislation of your customers country.
- bugs:
because of their development process in quite a short period of time (as1, as2, as3) every version has certain bugs that you'll have to work around.
bottom line:
- flash is great for multimedia-based content in specific target groups on predefined and confined specs.
the more your app should be able to grow, the broader the target audience and tasks your app has to fullfill the more you'll doubt your initial decision
cheers,
livenow
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053150#4053150
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053150
18Â years, 11Â months