The pragmaticObjects team is pleased to announce the release of pragmatic WebControls Version 0.5, the first publicly available version.

This release includes a set of JSP tag libraries that delivers an easy way for Java developers to seamlessly incorporate Outlook-style menu bar and tree components in any Java-based web applications: JSP, Struts and JSF.

Ease of use and cross-browser support are the first two and foremost requirements. pragmatic WebControls is released as Open Source under the BSD license.

Web site: pragmaticObjects
Demos:http://pragmaticobjects.com/demo.html

Downloads:http://pragmaticobjects.com/download.html

The taglibs are really great. + they are not even heavy like the ones done using flash.

Rajesh.

I am impressed with your philosophy to release these for everybody now, and for JSF "real soon now".
Web component frameworks like JSF, Tapestry, and Echo only start to shine when there are great components available for those frameworks... and Open Source components are a heck of a lot more attractive then commercial components.

I suspect that many see JSF as an opportunity to sell components.... but it makes much more sense for the rest of us to support Open repositories of components that we can all benefit from.

Hey Kevin,

I checked out the two components. Very impressive! I did have a question regarding the tree component. I have seen variations and different implementations of the tree so far and I haven't seen one where the user can "Remove" a node just as easily as you add a node. Do you have any plans to add the "Remove A Node" functionality. The solution I have resorted to is by using a Java Applet so that it can invoke a URL on Node click and retrieve it's children and if the children change, then remove the nodes appropriately. I have not seen the implemenation of "remove a node" in a DHTML version.

Any plans for implementing a 'remove node' option? Great job on the components.

Venkatt Guhesan
Aveda Technology, Inc.

Any plans for implementing a 'remove node' option? Great job on the components.Venkatt GuhesanAveda Technology, Inc.

Thanks for the suggestion. I will add that in the next version 0.6.

Looks very nice. Unfortunately the demos use frames, which are unlinkable. Are the usage of frames required?

The tree control can be used framelessly. Unfortunately, the outlook Bar requires usage of frame, ... at least for now. I understand that using frame is just simply not an option in many situations. In situations where frames can be an option and the controls are simply used as navigation driver, it may lead to some simpler coding in both JSP and Struts web apps.

We've been doing this for years...
We have build in-house controls for:
- Tree (with server-side events that can make thousand node tree efficiently renderable)
- Grid (with build-in paging, scrolling, etc.)
- ComboBox (much better then build-in poor HTML select tag)
- Drop down menus
- Buttons
- Tab Control
- Expandable blocks
- Set of statefull HTML form controls which hold their state in HTTP parameters on client side

When looking at ultimate web app HTML contols, what I would like to see is:
- controls with windowing like OO interface as well as JavaScript OO interface,
- controls that can render themselves in HTML,
- controls with server and client side events,
- controls that can render difference in their two states as JavaScript code that manupulates HTML DOM and executes in hidden frame, so there is no need for page refreshes!

But unfortunately, current frameworks are far behind this :(
There are much more that can be done regarding rich web clients even using current HTML/HTTP/JavaScript/DHML technologies...

Check out Coldtags suite also: http://www.servletsuite.com/jsp.htm

Check out Coldtags suite also: http://www.servletsuite.com/jsp.htm

Yes, I am aware of ServletSuite. There are many great and innovative JSP tag libraries there. But there is NOT anything that provides something like the Outlook Bar menu (not that I know of). There is a tree view, but it does not support for context menu and I think it requires a purchase.

Pragmatic Controls provides those missing links in ServletSuite, and it's Open Source.

this sounds cool..

When looking at ultimate web app HTML contols, what I would like to see is:- controls with windowing like OO interface as well as JavaScript OO interface,- controls that can render themselves in HTML,- controls with server and client side events,- controls that can render difference in their two states as JavaScript code that manupulates HTML DOM and executes in hidden frame, so there is no need for page refreshes!But unfortunately, current frameworks are far behind this :(There are much more that can be done regarding rich web clients even using current HTML/HTTP/JavaScript/DHML technologies...

I wouldn't say that the current frameworks are behind this -- you can do all this stuff with JSF today. Check out IBM's FacesClient components: http://www-106.ibm.com/developerworks/websphere/library/techarticles/0411_hasson/0411_hasson.html?ca=dnp-344 and Oracle's ADF Faces components: http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/index.html.
 Both of these component suites offer a lot of client-side and server-side functionality. Simplica's component suite does some of this stuff too: http://www.simplica.com.

You can find a full listing of JSF components at: http://www.jsfcentral.org/products/index.html#Components.

Kito D. Mann
Author, JSF in Action
http://www.JSFCentral.com - JSF FAQ, news, and info

But unfortunately, current frameworks are far behind this

How do you feel about doing things more abstract:

<dd:text id="productname" label="=id" .../>
<dd:selectOne id="productversion" label="=id" .../>
<dd:text label="=id" id="by" .../>
<dd:text label="=id" id="on" .../>
<dd:textfield id="title" label="=id" .../>
<dd:selectOne id="assignedto" label="=id" .../>
<dd:selectOne id="priority" label="=id" .../>
<dd:selectOne id="severity" label="=id" .../>
<dd:selectOne id="status" label="=id".../>
<dd:selectOne id="securitylevel" label="=id" .../>
<dd:commandbutton id="store" label="=id"/>

Automatic layout, data binding, possibility to implement different renderers and groovy as the script engine.

I wouldn't neccesarily agree that frameworks are behind feature-wise. What drains development time is configuration and setup time associated with each framework. Albeit, once you've done it, it's not too big of a deal. But newbies stumble on the ramp up time associated with each framework.

This is where JSF *should* help in particular, since one of it's design goals was to integrate easier into IDEs. Also, it's a standard, which is a bigger deal than folks think. Once a standard, vendors and third-party providers are more apt to buy in and provide solutions. This is also true for those that author training material. Struts has been able to make this leap because it's a strong product and has gained ubiquity.

Joe Pardi
dotJ Software
http://www.dotjonline.com
"Get tagged"

- controls that can render themselves in HTML,
...
- controls that can render difference in their two states as JavaScript code that manupulates HTML DOM and executes in hidden frame, so there is no need for page refreshes!

Now that I've learned about XMLHttpRequest, I believe that it is THE technology where shows the direction in which "traditional" web apps will evolve. Should be unvaluable for portals. Existing portals which reload a whole page when one portlet redraws itself just suck. Funny, XMLHttpRequest exists for nearly five years already, but only after Google team used it, everyone realized that we were sitting on the gold mine for all this time.

Don't call me Rolf, but I predict that in six months we will see a whole bunch of products based on XMLHttpRequest, and portals will be the major, major, major players.

Being able to redraw only single page component by using standard HTTP request/response cycle and standard HTML for presentation, paves the road to various "clean" web components. Would be great if XMLHttpRequest could be sent to a server other than that where original page came from, AFAIK currently this is prohibited because of security concerns. This would allow to use components built with different server technologies, like ASP.NET components, or Pragmatic components, and hosted on different sites and on different appservers. the components will be sent to a browser simply as small HTML pieces, and the browser would build a page from different construction blocks.

Compatibility of modern browsers is quite good, so these components will use XHTML, CSS and Javascript (and, hopefully, XML and client-side XSLT) and will be run in a single page. Isn't this a true component-oriented development?

t could be sent to a server other than that where original page came from, AFAIK currently this is prohibited because of security concerns. This would allow to use components built with different server technologies, like ASP.NET components, or Pragmatic components, and hosted on different sites and on different appservers. the components will be sent to a browser simply as small HTML pieces, and the browser would build a page from different construction blocks.Well, not a biggie. The main portal server will itself load HTML code for each component from trusted servers. Considering that each component is a FORM, there is no problem to route requests to a proper component with proper parameters. All in all, HTTP knows nothing about "events" or "properties" and it is up to an appserver how to deal with HTTP request parameters.

Arrgh! Preview and editing is desperately needed on TSS.

components. Would be great if XMLHttpRequest could be sent to a server other than that where original page came from, AFAIK currently this is prohibited because of security concerns. This would allow to use components built with different server technologies, like ASP.NET components, or Pragmatic components, and hosted on different sites and on different appservers. the components will be sent to a browser simply as small HTML pieces, and the browser would build a page from different construction blocks.

Well, not a biggie. The main portal server will itself load HTML code for each component from trusted servers. Considering that each component is a FORM, there is no problem to route requests to a proper component with proper parameters. All in all, HTTP knows nothing about "events" or "properties" and it is up to an appserver how to deal with HTTP request parameters.

This looks very interesting and I'm thinking of trying to use these controls in some work I'm doing now. Specifically, I wanted to add a tree menu, dynamically, via the Java APIs but did not see any examples(maybe I missed them?).

Are there any active forums for the community? I missed a link to any Sourceforge-type project. I see an email contact, but that's not nearly as useful as a forum or list.

Thanks,
Mike

This looks very interesting and I'm thinking of trying to use these controls in some work I'm doing now. Specifically, I wanted to add a tree menu, dynamically, via the Java APIs but did not see any examples(maybe I missed them?). Are there any active forums for the community? I missed a link to any Sourceforge-type project. I see an email contact, but that's not nearly as useful as a forum or list. Thanks,Mike

The following works are currently uder way:
1. Forum will be in placed no later than 02-22.
2. More samples illustrating dynamic data-binding (i.e. using Java APIs).
3. version 0.6

Please check back on the web site.

This looks very interesting and I'm thinking of trying to use these controls in some work I'm doing now. Specifically, I wanted to add a tree menu, dynamically, via the Java APIs but did not see any examples(maybe I missed them?). Are there any active forums for the community? I missed a link to any Sourceforge-type project. I see an email contact, but that's not nearly as useful as a forum or list. Thanks,Mike

The following works are currently uder way:1. Forum will be in placed no later than 02-22.2. More samples illustrating dynamic data-binding (i.e. using Java APIs).3. version 0.6Please check back on the web site.

Please visit pragmaticObjects web site and follow the "Forum" link to the forum discussion board.

FYI - The tree component works fine with Safari on Mac OS X but the Outlook bar doesn't. However the bar does work with Internet Explorer on Mac...

Just so you know ;-)
Stephan

Well, sounds quite nice, but where's the MVC ??? And why don't you provide javax.swing.TreeModel based tree views ? This would avoid thinking trees differently on Desktop and Web apps...

Look at this if you've got time :

http://www.rvkb.com/htmltree/doc/index.html

That's my small implementation of an HTML tree view, based on Swing interfaces, with event handling and custom rendering... I use it in almost every web app I make... Trees are everywhere actually :-P

It's not "taglib-ed" (but I don't care, a short JSP expression is to me strictly equivalent to an XML tag !), and you'd have to provide a "myXMLtree - to - swing treemodel" implementation to get it work with your XML files... But then you can handle real events (expand, collapse, and click). This is mandatory for trees that load sub-nodes dynamically on expand for example...

Have fun

Remi