portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vivek Kumar" <fireveloc...@gmail.com>
Subject Re: j2-admin refactoring in 2.2
Date Wed, 16 Jan 2008 15:33:34 GMT
I would like to start on j2-admin refactoring with wickets.
I want to create prototype for user browser portlet,
before that i would like list down all features that we are targeting
for this prototype .

Regards
Vivek Kumar

On Jan 16, 2008 3:57 PM, Dennis Dam <d.dam@hippo.nl> wrote:

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


-- 
Regards & thanks
Vivek Kumar

firevelocity@gmail.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message