portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: j2-admin refactoring in 2.2
Date Wed, 16 Jan 2008 05:49:00 GMT

On Jan 15, 2008, at 1:10 PM, Dennis Dam wrote:

>
>
> 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 personally have zero Wicket experience. I believe Ate has Wicket  
experience, as does Woonsan.
We have a number of people interested in working on this. So who is  
going to work on the first prototype?
Or maybe we should have several prototypes...

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

Yes, the messaging quite simple and easy to use. I think we can  
easily replace once the 286 container is in place.
I would also like to investigate Wicket event handling, although I  
don't want to tie to closely to it if its not comparable and easily  
portable to the portlet spec

>> 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?
>
Right.
Say you have 20,000,000 users. You don't return them all at once and  
load them into the user browser.
I would prefer the User Browser comes up empty, and then you can  
search on users and get a result set back that can be paged over


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