portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Woonsan Ko <woon_...@yahoo.com>
Subject Re: j2-admin refactoring in 2.2
Date Tue, 05 Feb 2008 10:58:44 GMT
Hi All,

I just committed a wicket prototype for user browser portlet to the trunk.
Because my gradual learning curve, it took longer than I expected.
Anyway, now I think we can discuss a little bit more on the j2-admin refactoring in 2.2.

If you build j2-admin by `mvn package' under /trunk/applications/j2-admin/ folder and deploy
j2-admin.war to the existing Jetspeed 2 (You may use the existing v2.1.3 system.), then you
can
choose a new portlet, 'j2-admin::WicketUserBrowserPortlet'.
You can insert this new portlet in the user management page for testings.

I wanted to finish user detail portlet this time, but I could not. I'd like to work on that
next
week. (This year, the Korean New Year, or Sol-nal, will fall on our February 7. So, I'll be
back
to work next Monday. Happy new year! ;-) )

This prototype will show the followings though it misses some search functionality:
 - How simply the application can be written with Wicket.
 - How widget components can be utilized and written.
 - How to access portlet api in Wicket application.
 - ...

Regards,

Woonsan


--- Vivek Kumar <firevelocity@gmail.com> wrote:

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



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ



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