[Zope3-dev] Portlets vs Pagelets

[Joachim Werner]

Hi!

Jean-Marc Orliaguet wrote:
> The problems raised in these goals are easily solved if the logic is 
> moved to python and why would you want to hard-code a UI? I am more 
> inclined to a Visual (C++, Basic) approach with UI widgets assembled 
> together than using some hardcoded template no matter if it is a webpage 
> that is being designed or a portal. I am sure that some users need to 
> update the webpage without having to learn page templates, don't they?

I think that's the way to go for a Portal/Portlet/Pagelet framework.

Actually, I am a bit disappointed that while the new Zope X3 
architecture improves a lot of things, it doesn't have that much to 
offer for programming sophisticated web frontends. This is no complaint. 
After all I could have added that stuff on my own ;-)

I'll now repeat what I've said a couple of times before: We'd need a 
real-life project that needs a very rich web frontend (e.g. a web-based 
groupware or similar) as a development testbed. The Zope X3 ZMI could be 
one of these candidates, too.

 From an application developer's point of view I'd like to not have to 
care about any HTML- or Javascript related implementation details, at 
least for the very first implementation of my application. Later I might 
fine-tune things like I would fine-tune the look&feel of forms and 
dialogs in a desktop application.

I'd like to be able to express my application logic and workflow and get 
a working web UI for free.

To get that done right for web applications (vs. fat clients) the 
framework has to make sure that all the limitations of HTML/Javascript 
don't have to be handled by the application developer from scratch again 
and again.

It's another question how far that should go. Here are two examples:

- For really advanced web-based UIs the framework should simulate a 
long-running session/process, so I can do things like this as easily as 
they can be done in, let's say, PyQt:

    answer = MessageBox.question('Do you want to proceed?',
             'Yes', 'No')
    if answer == True:
    	self.doSomething()

"MessageBox" would display a web page with the message and a "Yes" and 
"No" button. As soon as the user has made his choice the result would be 
returned to the main application process.

That would mean that the core application instance would keep state for 
every user. A related question is if we can move some of this to the 
client. E.g. the ASP.NET approach is that you can have input checking 
either handled by the client (using Javascript) or by the server.

- For less advanced scenarios, or where keeping state on the server 
would just be to costly, a less abstracted framework would do. The 
developer would have to keep the limitations of the stateless 
request-response paradigm of HTML/HTTP in mind, but the framework would 
try to help as much as possible, e.g.:

  - "widgets" on a web page would automatically get unique ids for their
    form actions and field names, so things don't get mixed up if there
    is more than one "applet" (portlet) on the page. The developer would
    be able to use non-globally-unique identifiers when he writes his
    application logic.

  - an advanced session framework would store state on a per-widget and
    user basis.

These are just random thoughts ...

What I am hinting at is that we'll need larger building blocks and hide 
more of the implementation issues from the casual application 
programmer. Let me compare this with Lego: We shouldn't require the 
children to carve their own lego blocks from wood and decide on the size 
and design of the connectors on an individual basis. They should get a 
box with all kinds of blocks in all colors and start building things 
from them ;-)



Cheers

Joachim Werner