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 Wed, 20 Feb 2008 12:08:00 GMT
Hi All,

I just committed a wicket prototype for user details portlet to the trunk.
So, you can add wicket user browser portlet and wicket user details portlet in the user admin
page
now.
This prototype includes i18n support, data table bindings, customized UI components, event
handling, etc.
By the way, I added some gif files and css definitions into the tigris layout templates to
use
wicket tabbed pane. So, if you want to see tabbed pane properly, you might need to copy
/jetspeed-portal-resources/src/main/resources/webapp/decorations/layout/tigris/css/styles.css
and
/jetspeed-portal-resources/src/main/resources/webapp/decorations/layout/tigris/images/tab_*.gif
manually.

Thanks.

Regards,

Woonsan


--- Ate Douma <ate@douma.nu> wrote:

> Woonsan Ko wrote:
> > 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.
> Great work Woonsan!
> 
> I've just updated and build j2-admin (with some local hacking to its pom.xml as the treecontrol
> and gems aren't yet build for 2.2).
> And yes, it works :)
> 
> But I don't have the time yet this week to properly review or discuss it, hopefully starting
> next week though.
> And hopefully we then have some additional plans set in motion too with respect to how
and where
> we will do further apps refactoring for 2.2 ;)
> 
> One thing relevant I noticed while updating is the "fix" you made with r615851 for the
> JetspeedSerializer implementation.
> Just FYI: I've marked r615851 myself as a TODO for revert as soon as I have time to look
into
> it.
> I have no problem with this temporary copying over of 2.1.3 interfaces and implementation,
but
> the real solution will have to be different, e.g. proper with 
> respect to the new JetspeedSerializer model I set up for 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! ;-) )
> 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.
> >  - ...
> Very cool!
> 
> Regards,
> 
> Ate
> > 
> > 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 
> 
=== message truncated ===



      ____________________________________________________________________________________
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