Re: Rialto Browser UI framework

I don't mind sharing any thoughts at all. I might even see if I can help
contribute in any other way at some point.

I've personally just started reading a book Wicket and it sounds like they
have an interesting seamless way of keeping state. Just something to look it
for possibly some ideas.

The main obstacle I see with making an external consumer based site will be
the JavaScript. This will ONLY come into play if you want the site indexed.
If it's just a site that external people, e.g. outside sales, customers,
vendors, etc. need to use no problems. The issue is if you want John Doe to
see come across your site with the a search. JavaScript is not web crawler
friendly as it manipulates the DOM and does not output HTML.

--
James R. Perkins


On Mon, Jan 25, 2010 at 08:33, Aaron Bartell <aaronbartell@xxxxxxxxx> wrote:

I would say that RPGUI needs to support both internal and external needs to
be effective. I wouldn't want somebody to adopt RPGUI for internal then
require them to find a different solution for external.

Through conversation with others I think it is fairly clear that RPGUI will
have to support both stateful jobs and non-stateful (which it pretty much
already does non-stateful, we just need more examples of fuller
applications
so people can see the breadth). The non-stateful could be used in
combination with the stateful. For example, you could have a non-stateful
RPGUI program that only knows how to return a list of valid customers based
on the criteria passed in. That returned list could then be used for a
variety of purposes (i.e. customer prompt, customer listing in a stateful
CRUD app, etc).

I must admit I wasn't sure how I felt about a framework like this at

first,
but I'm gaining some interest.

Excellent! What are some other things that are bothering you about RPGUI -
if you wouldn't mind expounding?

Aaron Bartell
http://mowyourlawn.com
http://mowyourlawn.com/blog/