portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Dam <d....@hippo.nl>
Subject Re: j2-admin refactoring in 2.2
Date Tue, 15 Jan 2008 21:10:13 GMT


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 here, let's first see if Wicket works (1). It's like a warmup 
excercise, before diving in. As for point 2 (the design) , I'd like to 
see a really slick GUI design made by a professional designer. Designers 
also have an eye for how to make html easily skinneable , etc.

My only concern is that there's a lack of experience in Wicket among the 
active contributors. Or am I wrong here? At least I'm a newbie in this 
area. Perhaps it is a good idea to get some advice from wicket gurus 
about the best practices for Wicket applications, and write them down 
first! At least then we all have some common, basic guidelines to 
follow. This can also be comething we do *after* the first prototype 
though, we can then combine our own experience with best practices 
obtained from the web / gurus.

Btw, sign me up for some wicket refactoring!

> ---
>
> 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
>

In my opinion, we can better keep the browser and detail portlets 
separate, since they are two different functionalities. Am I right when 
I say that we simply keep the portlet messaging between those portlets 
like it is now, but just change the view layer we use (wicket)? If 
that's the case, then later on we can simply replace the portlet 
messaging with the JSR-286 stuff and then we're done.

> 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.
>
> 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.
> 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?
>
> 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

I don't know what you mean with "virtual" ? You mean paging support?

> 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
> 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. 
> 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
> 8. Web 2.0 - make use of any web 2.0 features available in Wicket 
> (again I plead ignorance to these features)
> 9. leverage the Jetspeed AJAX API where applicable
>
> 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
>
> -- 
> 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


Mime
View raw message