future directions

[pmn92]

After reading a recent post on the user forum, it seems that a few subjects are touchy. Nevertheless there are a few topics that I like to ask:

deployment:
It is currently provided through xml descriptors, some info are persisted, others are not. Why is that? At every start the entire xml descriptors are read and it is not clear what is persisted, when changes are detected, nor even if the xml descriptors are consistent. As a consequence there is no real design for extension or customization. Is there any future plan on this topic?

layout:
Layout assignment is done through xml descriptor. That is a bit rigid compare to the ability to dynamically associate a layout to a page through the event mecanism for example. Any plan to improve it?

platform / solutions:
A few features are "solutions" rather than platform building blocks - themes, navigation and dashboard injection. Any plan toward a clearer separation?

theme:
Any plan toward an integration with YUI ?

These are just genuine questions, please do not see any criticism where there are not.

[theute]

"PMN" wrote:

deployment:
It is currently provided through xml descriptors, some info are persisted, others are not. Why is that? At every start the entire xml descriptors are read and it is not clear what is persisted, when changes are detected, nor even if the xml descriptors are consistent. As a consequence there is no real design for extension or customization. Is there any future plan on this topic?

portlet.xml is a deployment descriptor. portlet-instances and *-objects are just here for people willing to pre-populate the portal objects (instead of using the admin portet or as compliment). The portal structure needs to be persisted.

"PMN" wrote:

layout:
Layout assignment is done through xml descriptor. That is a bit rigid compare to the ability to dynamically associate a layout to a page through the event mecanism for example. Any plan to improve it?

Not sure i understand the question. You can change the layout programatically.

"PMN" wrote:

platform / solutions:
A few features are "solutions" rather than platform building blocks - themes, navigation and dashboard injection. Any plan toward a clearer separation?

Yes, but note that core is already the glueing part. Some parts should be exported though.

theme:
Any plan toward an integration with YUI ?

No, but better plans ;) See the presentation framework discussions. GWT comes in mind as an example of presentation framework usage. It will be part of JBoss Portal 2.8

These are just genuine questions, please do not see any criticism where there are not.

Good questions, please see the presentation framework discussions and see if you have ideas to bring on the table, a lot of the work has already been done but it's always interesting to see in users use-cases fit in the model.

[pmn92]

Layout:
I am interested, how and when can I change programmatically the layout of the page being computed?

For all other things I already have some code to cover my needs, I would not rely on features that are not clearly stated in the objectives.

I'll have a look at the presentation framework.

[pmn92]

Where are these presentation framework discussions?

By teh way, GWT is again solution oriented and a very ugly dev kit.

If JBP 2.8 is based on GWT I'll drop down Jbp and stay with 2.6

[theute]

Sorry i rephrase:
GWT comes in mind as an example of presentation framework usage. The presentation framework will be part of JBoss Portal 2.8

If you can do basic HTML and GWT you can do pretty much everything (Swing could also be an option ideally)

More:
* http://wiki.jboss.org/wiki/Wiki.jsp?page=PresentationFramework
* on this forum
* Code... but you're on your own, that's work in progress: https://svn.jboss.org/repos/portal/branches/presentation/

[pmn92]

Thanks for the pointer. Design ideas are nice, other text is too vague to get an idea. It seems to me that a presentation framework starts with an ajax framework and thus the choice of an ajax dev kit. YUI has low level and excellent concepts that would be very well adapted to a "framework" that would support building block "solutions" such as gwt or place holder for region and windows.
I would have no time to dig into the code as I amalready a full yer late on my product -(a

[theute]

No the presentation framework sure doesn't rely on an ajax framework. It's decoupled from the view actually.

If you want to base your view on YUI the good thing is that you can. But if your neighbor want it based on GWT (Which is quite popular, like it or not) he can, and if someone else want plain old HTML he can too.

The presentation framework gives you the necessary abstraction ! We won't rely on a technology, it changes too quickly, and that's why the presentation framework is born :)

[pmn92]

I don't see how you can support multiple ajax framework on the same page without being subject to side effects, especially when it comes to layouts.
If jbp team succeeds to do that, then it is awsome, I want to see it and at this point I don't see this as feasible. You need to fix the layout first and thus rely or provide a technology for that. All versions of jbp lacks of this concepts and still, 2.8 is not clear -"what is well thought can be explained with words" sorry for paraphrasing ...

[julien1]

The PF is a way to decouple the portal from its presentation layer so you can have the implementation of your choice:

- HTML (Classic)
- Ajax
- Flex
- Swing

the need really comes from the fact that the portal *must* not rely on a specific kind of presentation technology. For instance your portal should not behave differently if you use HTML or Ajax, what I mean by behave here is the portal logic, like if I click on page XYZ, it shows page page XYZ).

The PF does other things, I wrote a document that outlines it, you can see read it http://docs.google.com/Doc?id=dhfvtj95_1fnrk2f

We can discuss about it in that forum.

No the presentation framework sure doesn't rely on an ajax framework. It's decoupled from the view actually.

If you want to base your view on YUI the good thing is that you can. But if your neighbor want it based on GWT (Which is quite popular, like it or not) he can, and if someone else want plain old HTML he can too.

The presentation framework gives you the necessary abstraction ! We won't rely on a technology, it changes too quickly, and that's why the presentation framework is born :)

[pmn92]

ok, then it is like other "solution oriented" features, the only advanced feature is to choose among 4 approaches without defining concepts.

The layout - currently provided with a jsp and renderer - is defined at page level not portlet level and that 's the point. Flex is easily embedded in ajax and ajax is only an extension of "html classic", ajax is beyond the portal logic, your approach is not clear or flaked.

[julien1]

"PMN" wrote:
ok, then it is like other "solution oriented" features, the only advanced feature is to choose among 4 approaches without defining concepts.

Today the UI presentation for a portal is a technology which is volatile (not so much). Yesterday it was classic HTML, today it is also Ajax, and tomorrow what will it be ? So should I rewrite the whole portal when a new client technology becomes mainstream on the market ?

This is what PF is about.

Beside isolating the core portal from the UI layer is to ensure that the client state (whether it is HTML, Ajax, etc...) is always correct.

Consider this scenario:

1/ you interact with portlet A (process action)
2/ A update its render parameters and fire an event
3/ Portal decides to deliver event to portlet B on same page
4/ portlet B update its render parameters upon event
5/ meanwhile portlet C also on the same page as its cached markup that has just expired (so it is stale)

after this serie of interaction, what the client needs to see is the update of the markup of portlet A, B and C, whatever the client UI technology is.

in case of "Classic" nothing needs to do as we compute the page on each refresh

in case of "Ajax", the client layer impl needs to detect that the 3 windows on the screen are stale and replace them during the single interaction.

Do you consider that as:

1/ a commodity that you would expect from an enterprise class portal
2/ an advanced feature
3/ 1 + 2

This is also what PF is about.

"PMN" wrote:
The layout - currently provided with a jsp and renderer - is defined at page level not portlet level and that 's the point. Flex is easily embedded in ajax and ajax is only an extension of "html classic", ajax is beyond the portal logic, your approach is not clear or flaked.

Can you explain more what you mean ?

[pmn92]

The point is that I agree with most parts but there is a missing point : page control... Portlets are not exactly independent from each other, first there are interactions defined by events and second there is a layout in the page, where windows are place holders to display portlet content. The second point is missing in jbp, unless I am mistaken, there is no way (or insufficient) way to change the layout of a page upon event.

Anyway, as long as "basic html" is maintained, I am ok.

[julien1]

I think that changing the layout of a page is a portal feature.

Can't you do that using a portlet today to update the portal page structure ?

"PMN" wrote:
The point is that I agree with most parts but there is a missing point : page control... Portlets are not exactly independent from each other, first there are interactions defined by events and second there is a layout in the page, where windows are place holders to display portlet content. The second point is missing in jbp, unless I am mistaken, there is no way (or insufficient) way to change the layout of a page upon event.

Anyway, as long as "basic html" is maintained, I am ok.

[pmn92]

This is the second time I have been answered that it is possible without indicating the way to do it.

Please do ... I have done my best to read PortalNodeEventListener, WindowNavigationEvent and could not find any way of doing this there.

Same issue for changing region for a portlet, where, when?

By the way, I posted an example of a real concept of layout - layout being able to embed layout - Ajax dev kit have this now well defined, not only YUI.

This really is layout and is needed.

[theute]

"PMN" wrote:

By the way, I posted an example of a real concept of layout - layout being able to embed layout - Ajax dev kit have this now well defined, not only YUI.

This really is layout and is needed.

Agreed but if i understand what you are saying, this is on top ot the presentation framework not a PF concern.

So you would have a YUI implementation of the PF that deals with the layout. And we will provide a layout mechanism for HTML.