portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: j2-admin refactoring in 2.2
Date Wed, 16 Jan 2008 23:36:24 GMT
Hi guys,

Sorry for responding so late but I'm away in Reading, UK, for a JSR-301 F2F meeting since
As I had the bad luck of a non-functional wireless network card in my laptop I've been "blind"
until yesterday evening, and during the day I don't have a 
connection either at the meeting place.

(FYI: Yesterday evening I didn't have time to properly process my email either as I had to
figure out Jetspeed 2.1.3 deployment instructions on JBoss 4.2.1 for 
a client. I got that working nicely and I'll put it up on a WIKI page soon).

Anyway, I'm back online now and have provided a lot of comments on this below.

I'll fly back home tomorrow evening and will be back in d2d business on Friday.

David Sean Taylor wrote:
> I would like to start a discussion on the j2-admin refactoring for 2.2
>  From a discussion with Ate:
> ---
> One thing I think we really need to determine first is what the goal is.
> I can easily think of many different ones, like:
> 1 - only rewrite (one or more of) of the portlets but stick to the 
> current features and (most of the) ui,
>   just to build up experience with Wicket and see how it goes
> 2 - allow a ui design overhaul but stick to the current features
> 3 - allow for some functional redesign/improvements (dangerous: 
> when/where to stop)
> 4 - do a complete functional overhaul, e.g. like for the security 
> portlets, (like JS2-27, JS2-241)
> My current idea is we probably should start with the first or possibly 
> second goal, anything beyond that is very difficult to manage and plan for.
> ---
> I agree that a first prototype is best.

> Which portlet?
> Well, many of the portlets are actually made up of two portlets, such as 
> the User Manager or Role Manager
> But we still do not have JSR-286 support
> So maybe its best to combine the browser and details portlets into one 
> portlet.
> There are advantages to both approaches.
> The interesting part of separating the browser from the details is that 
> the browser can be used in combination with other details.
> Too bad the 286 support isn't resolved yet
Not much we can do about that at this time.
Pluto 2.0 trunk isn't "ready" enough yet as a properly compliant JSR-286 container.
But it'll get there sooner or later, also depending on how much time we'll be able to put
in to help out with that.
Actually, investigating what is going to be required to migrate to Pluto 2.0 (while it isn't
fully "frozen" on SPI etc.) might be something to consider.
There will certainly be issues, incompatibilities and other annoyances which we can help identify
and potentially "fix" before Pluto 2.0 is released so our 
migration path will be somewhat easier and integration can be done better / natively.
But this is a different subject we might want to discuss in a separate thread...

With regards to using JSR-286 coordination features (events, public render parameters), there
is no support for that in Wicket yet, mainly because of lack of 
time on my side and JSR-286 not yet formally released and available to build against. But
it definitely is something high on my TODO list, and with the recent 
Pluto 2.0 trunk merge there now is a codebase to build against.

For the time being, my preference would be to prototype using a single Wicket portlet with
both a browser and details panel component.
As Wicket really is component based, defining these archetype components as "standalone" panels,
we can start out with integrating them initially on one Wicket 
Page. Once JSR-286 support has arrived, it should be possible to simply split these up in
two different Wicket pages, served by different portlet (instances).

Also, these archetype browser and details panel components really should be written such that
they are easily extendable so we can then reuse them for many 
different portlets, User/Role/Group management and maybe even others too.

> I think the Role Manager would be an interesting one to start with. Its 
> not as complicated as the User Manager, but has the 1 to many type 
> requirements that recur in many other admin portlets.
> Of course this is open to discussion and I invite your comments.
I agree Role Manager or Group Manager are good starting points, Vivek indicated though he's
interested in starting with the User Manager.
It might actually be a good idea to start with 2 portlets as that will allow as well force
us to create reusable and extendable archetype components.
Reuse and extendability in my view are the key architectural features we do need to deliver.

As Dennis also indicated he wanted to help out, I propose Dennis and I start working together
on a Role Manager portlet, and Vivek could start with the User 
Manager. Of course, we first will need to flesh out our common requirements and discuss and
come up with a design for it.
Everyone interested is of course more than welcome to join forces and help out, with discussions,
investigating requirements, design, review, code, patches, etc.

> Before we go too far I would to give anyone who believes JSF is a better 
> choice for writing the admin portlets a chance to speak up now.
> I think there are some advantages to JSF, such as being the standard, 
> and having a rich set of components.
Although I'm a bit biased of course as Wicket committer and primarily behind its portlet support,
I'd like to provide my view and preference to use Wicket.

JSF indeed is the standard and there are many rich components out there. I definitely think
JSF will be (not is) a valid framework for portlet development which 
explains my interest and role in the JSR-301 EG which is all about that.
But the current JSF (1.2) spec and neither the different implementation (MyFaces, Sun RI)
are currently very good at supporting portlet development and behavior 
isn't always quite what you'd expect and need. That is why JSR-301 now is defining a JSF Portlet
Bridge spec for, to cover the defiances and define the proper 
behavior in a portlet environment. That spec isn't ready yet, although a JSR-168 Bridge spec
review probably will be soon be ready.
The JSR-301 Bridge though isn't targeted to developers but to the JSF core implementors, to
allow them to provide a consistent and standard implementation.
At any rate, proper portlet support by existing JSF components is variant to say the least,
and often very much tied to specific portals (Jetspeed not being one 
of the main players in this respect).
But still, it is/should hopefully be doable to "properly" rewrite the j2-admin portlets in
JSF too.
That still doesn't make it the best framework to use though.
My own experiences with JSF hasn't been very favorable, I personally don't very much like
the "model" and architecture behind it and requires too much 
"plumbing" to my taste.

Using Wicket on the other hand has been very refreshing. The fact that you (hardly) need any
xml based configuration, everything is Java based and refactoring 
and extending functionality really is a breeze. And the very clean HTML *only* markup usage
allows true separation of tasks: UI design now can fully be handled 
by proper designers, no need for the developers to look after. That alone already "sold" me
to Wicket as I (and in my experience most Java developers) am very 
bad at drafting up a nice and good UI design.

And the extendability of Wicket is I think unmatched by almost any other framework, including
JSF. Package your component in a jar, including (example/base) 
HTML markup and simply start using *or* extending it to your taste for your own project or

Finally, although Wicket is still young, it already provides a wealth of base and reusable
components. Its nothing compared to what is available in the JSF 
market (some costing quite a lot of $$$), but for our requirements I think its already more
than we need right now. Ajax support for instance is fully 
integrated in the framework and needs zero javascript coding. Furthermore, Wicket transparently
provides a server-side fallback mechanism when the client 
doesn't support/allow javascript execution, so your application still will work as expected!
Now that is a very cool feature I think (and very important for 
organizations like the Dutch government which demands support for non-javascript enabled clients).

For anyone yet unfamiliar but interested to see some cool Wicket examples running: http://www.wicketstuff.org/wicket13
NB: that default Wicket examples application can also be deployed and runs very nicely in
Jetspeed 2.1.3 :)

> What I like about Wicket is that it is component-based and extensible. I 
> am always dealing with extending the admin portlets, especially the 
> self-registration.
> I would like to see how easy it is for someone to extend a Wicket 
> component, can anyone explain that in a paragraph or so?
I'm too tired right now to dive into this and lookup a simple example, but the wicket wiki
contains a wealth of examples and instructions for doing so, see:

NB: I seriously advise anyone not 100% familiar with Wicket (I'm not) to buy and read "Wicket
In Action".
Its not out yet but you can buy MEAP access and most of the book is now finished and available
for download (once you bought it):

It *really* is a very good book and it'll bring you up to speed with Wicket, and especially
the more/most essential "Model" in the framework. Everyone needs to 
at least read that chapter (5. Understanding models).

> Other requirements I am looking to properly implement this time around:
> 1. Virtual -- all browser must be virtual. We should not load all users 
> into the user browser
Definitely, and this really comes down to defining and using a good "detachable model" in
Wicket terminology.
Furthermore, this most likely goes to the underlying UserManager api which currently isn't
very good at supporting and providing subset query results.
On the UI side, Wicket has some very nice "paging" table/tree components which we can leverage
for this.

> 2. Extensibility - we need an easy way for users to customize and extend 
> the admin portlets
>     where we have done a decent job with this in portlets like the User 
> Details, having a large set of preferences,
>     I recently went through extending the User Registration portlet and 
> kept running into hard-coded features
>     All hard-coding has to go and we need to better consider how users 
> can easily extend the portlets
>     I am hoping leveraging Wicket can help here
This definitely needs to be one of our primary goals from the outset, so +1

> 3. Document features in help mode, about mode. The admin portlets are 
> not well documented. Lets not neglect that responsibility this time around.

> 4. support edit_defaults in all portlets

> 5. Notifications - not all, but some portlets are not properly hooked 
> into notifications (such as deployment events -> PAM portlet)
>     or the profiler portlet is not notified of profiler changes made 
> during an import. 
Although I haven't given this much thought yet, we could provide some kind of listeners support
in our Wicket detachable model(s).
By designing for /invalidate/flush/refresh etc. events and then hook that up to some kind
of event dispatch mechanism this should be quite doable.
And once JSR-286 comes around, we can then leverage proper Portlet Events to drive this.

> 6. Software Design - lets do a prototype first. then check it in for 
> review and comment, and iteratively design from there

> 7. Web Design - I believe the portlets should be skinned with a new 
> decorator to introduce a new, modernized feel to these web1.0 portlets
We do have a UI designer at the company, I can investigate if we can "borrow" him a bit to
come up with a slick new UI.

> 8. Web 2.0 - make use of any web 2.0 features available in Wicket (again 
> I plead ignorance to these features)
I propose we use Wicket Ajax support as much as possible, especially as Wicket provides server-side
fallback when not available on the client.

> 9. leverage the Jetspeed AJAX API where applicable
That might not be so trivial to do I think, and I'm not sure its the right way to go either.
I do see the benefit of leverage the Jetspeed AJAX API as "framework independent" API, but
Wicket build in Ajax support really is self contained, e.g. only 
usable for interacting with Wicket components and models. That doesn't mean we cannot write
and emit our own Ajax interactions for Wicket, but leveraging the 
Jetspeed AJAX API from the client will not be "connected" to the Wicket components and thus
synchronizing their state with the underlying (changed) Jetspeed 
data won't be trivial and probably require extra roundtrips and more complex code anyway.
In my view, the idea would be to use Wicket models to hook up on the Jetspeed services directly.
Technically, I don't think we need nor should add another 
abstraction layer between that.

> Finally, I want to move the j2-admin application out of Jetspeed and 
> into a new Portals project, Portals Applications
> I know that j2-admin can only be used by Jetspeed, but I am of the 
> opinion that it should be released on its on release cycle
Yes, no, yes.
We've discussed this before, and I'm all for a new Portals Applications project.
And I also agree we need to move j2-admin (and probably jetspeed-layouts) out of main Jetspeed
tree and give them (potentially) their own release cycle.

But, in my view the scope of "Portals Applications" should be for "generic", e.g. not Jetspeed
only/specific apps, like our rss application or the Bridges 
example apps (JPetstore etc.)

For Jetspeed specific apps like j2-admin and jetspeed-layouts, I think they will always be
tied to a specific version (or range) of Jetspeed, which makes it 
likely they will follow its release cycle too. Maybe (and there is the benefit), intermediate
update/fix releases of these apps might follow independently, but 
once a new Jetspeed release is done, most likely we'll need/want to release updated/enhanced
j2-admin and jetspeed-layouts too.
Anyway, as I said, I'm all for moving these apps out of the core jetspeed trunk, so they can
be checked out and maintained more or less independently.

To support this, we could restructure our current jetspeed svn source tree as follows:

            (different portal profiles, like demo, base, tomcat, geronimo, etc.)
   \... (maybe site/docs/tutorial etc.)


One important task to handle splitting up our codebase, however we do it, is setting up the
required JIRA project(s) for it, as we use that as main/driving tool 
for managing releases. Too bad though JIRA still cannot handle "subprojects" with their own
release versioning.



> -- 
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com <mailto:david@bluesunrise.com>
> [office] +01 707 773-4646
> [mobile] +01 707 529 9194

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message