Re: Rialto Browser UI framework

[Aaron Bartell <aaronbartell@xxxxxxxxx>]

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/


On Mon, Jan 25, 2010 at 10:20 AM, James Perkins <jrperkinsjr@xxxxxxxxx>wrote:

> I think the render kit approach is a good idea.
>
> So it looks like RPGUI will be used more for internal or portal style
> applications and not consumer based ones. Which I guess is where it makes
> the most sense anyway...
>
> Is RPGUI going to be component based? Not sure how that would work off the
> top of my head.
>
> I must admit I wasn't sure how I felt about a framework like this at first,
> but I'm gaining some interest.
>
> --
> James R. Perkins