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 Wed, 16 Jan 2008 10:27:56 GMT
David Sean Taylor wrote:
>
> 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 don't mind starting on Wicket, but I think it's best when people who 
are more experienced with Wicket first make a small prototype. After 
that the newbies can jump in, and take the prototype as a reference. It 
saves the newbies a lot of time, and will produce the prototype faster.


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


Ah ok, sounds like a good feature. Do we already have a standardized 
paging API? Might be a good time to build one.. I already have a piece 
of (Open Source) code btw we could use for that.


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