Carsten Ziegeler wrote:
It would be great if more than the two of us would be interested in the
portal stuff. But I think we are very near to a cleanup version which
I'll start to document around christmas (hopefully) and then others will
hopefully join in.
Yeah, it would. I'm not sure why this is the case. I find the portal to
be a great way to build any website, whether it needs the features of a
portal or not.
Hmm, I'm not sure but I think the current approach is more flexible. You
can expand (maximize) a portlet within any composite layout (tab,
column, row etc.). The "search layout" method is only called once when
the event is fired. It traverses the parents (which might be two or
three objects) and I think this is pretty fast. For example if you have
the use case that the tab is your root layout and it contains three
columns. Now the first column is "static" which means its always
visible. You can now maximize one of the portlets in the other two
columns. In this case, the tab is visible, the first column is rendered
unchanged and the remaining two columns are "replaced" by the maximized
portlet.
I'm not sure if the solution from 2.1 can handle these use cases in a
generic way?
You make some good points here and the behavior is certainly correct. It
seemed to me that the search layout was called for each layout as it was
being processed, but I could be wrong. The solution I added in 2.1 was
to essentially have the AspectRenderer and RendererContext keep track of
the state of the portal as they traverse downwards. I think the end
effect could be the same, it is just the manner in which the determining
the state of the parent(s) that is different.
2. I was thinking more about the issue of writing out the layouts when
preferences are changed and I think the right way to handle that is to
not save the "dynamic" preferences with the layout. I think we should
save them as something similar but not change the layout for that. I
think that that should handle the problem I mentioned to you where
layouts are dynamically generated. WDYT?
Hmm, sorry, I can't follow you here. The preferences are part of the
coplet instances, so whenever the preferences change, the coplet
instances change while the layout remains the same.
I don't know why I keep forgetting and saying that the preferences are
stored in the layout. Yes, of course they are in the instance data
which isn't as big of a problem.
3. I'm just curious on if you borrowed the deployment code or ended up
writing it all yourself.
I started borrowing the code from jetspeed-2 but while adapting the code
I found out that it contained some bugs and seemed to be incomplete
(undeployment). So I used that code as a frame and rewrote most parts of
it. For example, j2 uses listeners for deployment, we use our event
mechanism. There are still some parts containing the original code, but
I'll rewrite them as well to make them better fit.
Sounds good to me. Speaking of events, have you made it so that events
which are not convertable cannot be exposed in urls? It looks like
trunk is now using page labels by default, however they still appear to
be a request parameter We had spoken about moving the page labels into
the url path. If we know that only convertable events are coming in from
the browser I can clean up the page label stuff some and I can look into
moving the page labels into the path if you would like.
4. Do you have any other features planned?
Hehe, I have dozens of ideas - as always - most of them are not concrete
yet.
I'll finish the deployment stuff hopefully before the ApacheCon. Then
you can deploy jsr 168 portlets, wsrp portlets, Cocoon pipeline based
stuff etc. by just droping a an archive or a configuration file into the
deploy directory.
How will this fit in with the portal tools? I looked at that when it
was first submitted but I'm not using that code at all in my sites.
However, I know that I am going to need to get into more of the portal
management aspects pretty soon.
The transformers need a redesign as well - we have several overlapping
transformers - so cleaning them up is a must.
I'd also like to make the PortalGenerator and the Transformers
ThreadSafe components (i.e. - not poolable). Eventually, all the Cocoon
pipeline components should be also. Right now it looks like there is
only a ThreadSafe version of the FileGenerator in trunk.
Finally I would like to rewrite the profile handling. One of the
original ideas was to a profile that consists of several profiles which
are linked (through the link layout). For example, you will have a
portal page where some portlets are "static" which means they are always
available for all users and only one area is customizable by the user.
With linked layouts you end up having one static layout shared by all
users and one customizable layout for each user. This would reduce load
time amd memory usage.
This sounds like a good idea and is something I'm sure I could use.
But for most things I don't have any clear designs etc. - I've just some
ideas that I start to implement/discuss when I have time to.
You might consider opening jira incidents as enhancement ideas where we
can bounce possible solutions around.
Ah yes, and there is of course all this ajax stuff - I would like to
have a portal which has the same nice features like windows live with
drag and drop and so on...but I fear this will take some time to
implement correctly...
Yeah, the Ajax stuff has become a very hot topic. I have guys dying for
2.2 so they can have Ajax in the portal. Unfortunately, I haven't spent
a lot of time working with Cocoon Forms and know even less about Ajax.
Ralph
