Plocit is a lightweight toolkit that can be used to develop a Rich Internet Application rapidly. Plocit does not require an application server in order to run; however, it can easily be used in a J2EE environment.

Plocit is implemented as a Java Applet and can be embedded in a web page, launched over the web using JNLP, or run from the command line. A Plocit application is described in a set of XML files that can be created in an easy to manage modular structure.

Some notable features of Plocit are:

• A rich component set including Charts, Tables, Lists, Text Editor, ComboBox and Audio.
• Hierarchical Folder layout with an expandable folder tree.
• On-demand loading of data. Data is loaded from the back end only if and when it is needed and is cached on the client.
• Streaming Data. Charts, Tables and Text elements can be updated real time without needing to reload the data or application, e.g. bars in a bar chart expand and contract as data streams in, values in Table cells change, etc.
• Print Tables with excellent page layout facilities for multi line headers and footers.

There is both an online demo and tutorial with code examples for every Plocit element to make the process of developing a Plocit application quick and easy. Plocit requires Java version 1.5 or better.

Other Resources:

• Online demo
  
• Example deployment scenarios
  
• Tutorial
  
• Repository of example Plocit applications
  

This framework is a joke ?

The entire world is scaping of "applets" and "client side solutions" , and now this "framework" is take back 1996?

This framework is a joke ?

Obviously to the people that spent many hours writing the code it's no joke.

But I cringe when I see "applet" plus "requires Java 1.5 or better". Personally, I'd look at Flash if you need something beyond DHTML.

This framework is a joke ?The entire world is scaping of "applets" and "client side solutions" , and now this "framework" is take back 1996?

Hmm. They are? I am trying to escape the redo of 3270 screens (read browser apps).

I think there is a real need/demand for rich client frameworks, Plocit is not it though. Perhaps what is more
important is a set of patterns specifically tailored to
rich client applications. I know that the term 'rich-client'
is very loaded so this is what I mean here.

- A webstarted applications that talks to remote servers.
- Nothing to do with html (ajax is not what I need), I want
extremelly rich clients, drag&drop etc...

You have frameworks like Spring's Rich Client etc.. Although
it addresses some of the issues other important issues are
left, for example in your rich-client you have a model of
the data held in the server, how do I keep this model/state
(which is essentially a cache) updated. Note, most solutions
I have seen tend to focus on swing components that are split
into client and server parts. I want support at higher
levels, my models appear in many ui components.

I would love to discuss this with other people who have
similar requirements.

A webstarted applications that talks to remote servers.

I've had great success using XML-RPC as a fast (enough) communication mechanism between client and server. I've used a JavaScript-based XML-RPC API from jsolait.net. But there are many other choices for remote invocation.

in your rich-client you have a model of
the data held in the server, how do I keep this model/state
(which is essentially a cache) updated

I'm using Spring MVC on the server side and created the XML-RPC servlet by extending the AbstractController. That controller is generic and only exists as an access point for cached data. I use JBossCache as the caching mechanism, although, once again, many could argue for their preferred caching API. JBossCache keeps the data "fresh".

I hope I'm addressing your real question and not something that's obvious to you.

Thanks for the input, I have a couple of questions.

I've had great success using XML-RPC as a fast (enough) communication mechanism between client and server. I've used a JavaScript-based XML-RPC API from jsolait.net. But there are many other choices for remote invocation.

I don't know much about jsolait, but a javascript-based xml-rpc sounds like your client is web based (as in html/javascript). Is that right?

I'm using Spring MVC on the server side and created the XML-RPC servlet by extending the AbstractController. That controller is generic and only exists as an access point for cached data. I use JBossCache as the caching mechanism, although, once again, many could argue for their preferred caching API. JBossCache keeps the data "fresh".I hope I'm addressing your real question and not something that's obvious to you.

Here it sounds like you are talking about server-side caching. What I was refering to was client-side caching.
The clients I have in mind are Swing-based applications which maintain a cache of some of the data held at the server to improve responsiveness. What I have struggled with is coming out with a nice architecture/pattern/framework or whatever else you may call it, to handle this type of situation.

We are using Hibernate and POJOs in server (EJB application). We are using Swing in client applications, but our framework connecting POJOs directly to Swing components. The framework takes care of updating POJOs when user changes data. Those same POJOs are the sent back to server when user wants to save data. We still must implement EJB methods like readEntity, saveEntity, but Hibernate automates persistence and Swing framework automates showing data in a view. And both tiers deal with the same model objects.

We also have a framework for remote calls, that encapsulates EJB lookups, authentication, authorization etc. so finally coders deal pretty much with POJOs only.

We are using Hibernate and POJOs in server (EJB application). We are using Swing in client applications, but our framework connecting POJOs directly to Swing components. The framework takes care of updating POJOs when user changes data. Those same POJOs are the sent back to server when user wants to save data. We still must implement EJB methods like readEntity, saveEntity, but Hibernate automates persistence and Swing framework automates showing data in a view. And both tiers deal with the same model objects. We also have a framework for remote calls, that encapsulates EJB lookups, authentication, authorization etc. so finally coders deal pretty much with POJOs only.

Yes this architecture is more like what I had in mind. The problem I have though is how do I keep the state of the model objects consistent (for example does your client poll the server for changes, or are changes sent to the client) Remember that in my scenario I can have many clients running concurrently. Or does your application talk to the server everytime the user changes the view he is using?

We are using Hibernate and POJOs in server (EJB application). We are using Swing in client applications, but our framework connecting POJOs directly to Swing components. The framework takes care of updating POJOs when user changes data. Those same POJOs are the sent back to server when user wants to save data. We still must implement EJB methods like readEntity, saveEntity, but Hibernate automates persistence and Swing framework automates showing data in a view. And both tiers deal with the same model objects. We also have a framework for remote calls, that encapsulates EJB lookups, authentication, authorization etc. so finally coders deal pretty much with POJOs only.

Yes this architecture is more like what I had in mind. The problem I have though is how do I keep the state of the model objects consistent (for example does your client poll the server for changes, or are changes sent to the client) Remember that in my scenario I can have many clients running concurrently. Or does your application talk to the server everytime the user changes the view he is using?

You might want to check out cajo then.

Yes this architecture is more like what I had in mind. The problem I have though is how do I keep the state of the model objects consistent (for example does your client poll the server for changes, or are changes sent to the client) Remember that in my scenario I can have many clients running concurrently. Or does your application talk to the server everytime the user changes the view he is using?

It's hard to be sure that all model objects are consistent for all users in presentation layer (no matter what technology you are using). In our case, users deal with their "own data" so I usually just cache everything in client application (when data is read for the first time). However, my framework has a mechanism, that automatically checks via database timestamp column, if somebody else has changed the row to be updated to database. If so, an exception is thrown and user must react to this somehow (by overriding changes or merging data).

But of course, if your application automatically needs to show data that was just updated by some other user, then you need to build more sophisticated mechanism (for example "pushing" changes via JMS to client side).

It's hard to be sure that all model objects are consistent for all users in presentation layer (no matter what technology you are using). In our case, users deal with their "own data" so I usually just cache everything in client application (when data is read for the first time). However, my framework has a mechanism, that automatically checks via database timestamp column, if somebody else has changed the row to be updated to database. If so, an exception is thrown and user must react to this somehow (by overriding changes or merging data).But of course, if your application automatically needs to show data that was just updated by some other user, then you need to build more sophisticated mechanism (for example "pushing" changes via JMS to client side).

I agree with what you are saying, I was just wondering if anyone has come up with some good approaches/patterns for dealing with this type of scenario. I also plan to cache 'most' of the data at the client. I would also use database timestamps to figure out when things change at the server, instead of 'pushing' the data through jms I plan to have these changes propagated to the client whenever he talks to the server as well as having the clients periodically check for changes. Although JMS would make more sense it complicates deployment, clients and servers have to open firewall ports etc...

Yes, it would be nice to have a framework that would offer some help for refreshing cached data in a client. JMS certainly has some technical problems, but some kind of refreshing mechanism during remote calls would be useful. However, I'm afraid performance will be a problem if lots of cached data needs to be checked, refreshed and sent back to client.

Yes, it would be nice to have a framework that would offer some help for refreshing cached data in a client. JMS certainly has some technical problems, but some kind of refreshing mechanism during remote calls would be useful. However, I'm afraid performance will be a problem if lots of cached data needs to be checked, refreshed and sent back to client.

https://cajo.dev.java.net/

in your rich-client you have a model of the data held in the server, how do I keep this model/state(which is essentially a cache) updated. Note, most solutions I have seen tend to focus on swing components that are split into client and server parts. I want support at higher levels, my models appear in many ui components.

I think I understand what you want and I think this can be added to Plocit but if you can send me some more detailed information (like specific requirements and examples) to damian[AT]herculeez[dot]com I may be able to understand your needs better. The way I read it you want to create a data model that is used by many GUI components and have the data updated in the client whenever it changes on the server (and possibly vice versa).

Drag&Drop is certainly a prospect for future development.

The latest version of Plocit includes a 2 way synchronized merging Data Model. At the moment Text Fields and Charts (1 way) are supported and more GUI components will be upgraded to support a Data Model with each release.

Drag&Drop will be supported very soon.

Feature requests are most welcome.

Applet has never been able to rule the market due to its disadvantages. And now with Ajax, it makes lot a more easier for even Web developers to start writing RIA applications which was never possible with Applets.

@S
http://www.pcmspace.com

Applet has never been able to rule the market due to its disadvantages. And now with Ajax, it makes lot a more easier for even Web developers to start writing RIA applications which was never possible with Applets.@Shttp://www.pcmspace.com

The more I look into Ajax the more I dislike it. Sure you can do alot with it and javascript (including things like incremental download of server data, drag and drop etc ...).
The problem is that these applications are very hard to maintain, javascript is simply not adequate for large applications. As for applet, I also don't like them in general (mainly to do with issues related to the user experience which can be confusing, is it a webpage? is it an application? etc...) For the type of application I am working on currently I think a swing-based webstarted application is the way to go.

Hi,
my very recent experience on rich client web applications is using the NextApp's Echo2 framework [http://www.nextapp.com/platform/echo2/echo] (free to use also for commercial purpose) along with EchoPointing New Generation components [http://echopoint.sourceforge.net].

I've built a rich client applications in some hours following the Swing logic. All information between client and server travel in XML format using Ajax on the browser side.

There are many components and it's easy to extend their.

Unfortunately the documentation is not rich, but the forum is quite frequented ;-)

Just my 0,02€

bye,
Luca Garulli
Blogging on: http://zion-city.blogspot.com
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
www.OrienTechnologies.com - Light ODBMS, All in one JDO solution

I would say the best flavor of RIA frameworks is OpenLaszlo.
http://www.openlaszlo.org.

A number of people in this thread seem to be looking for something that automatically binds their server-side data to client side UI controls.

Asperon has just such as thing, and has developed a server-side API for this. A POJO version of the server-side API will be released shortly.

You can download a demo at http://www.asperon.com/downloads.html