You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Woonsan Ko <wo...@yahoo.com> on 2008/02/05 11:58:44 UTC
Re: j2-admin refactoring in 2.2
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 <fi...@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....@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
Re: j2-admin refactoring in 2.2
Posted by Ate Douma <at...@douma.nu>.
Hi Woonsan,
I finally found some time to update and try out the new Wicket portlets.
Wow!
Works very well (only Portlet Edit Mode isn't implemented yet) and browsing through the code now very easy to read and understand how all things work.
Although code reduction isn't first priority I can already see how we can build reusable (panel) components with common behavior to be used for other (admin)
portlets too.
Great work and definitely something I'd like to get my hands dirty on too (well, when I find time that is).
One area I think we need to look into is the messaging / synchronization / event handling between portlets / Wicket Pages.
I know that's also not the first goal here, but it definitely becomes more of a target now that we have a much better development model for the core portlet
features.
Maybe a possible solution is described here: https://issues.apache.org/jira/browse/WICKET-1312
I haven't reviewed that yet though.
Regards,
Ate
Woonsan Ko wrote:
> 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 <at...@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 <fi...@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....@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: j2-admin refactoring in 2.2
Posted by Woonsan Ko <wo...@yahoo.com>.
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 <at...@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 <fi...@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....@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
Re: j2-admin refactoring in 2.2
Posted by Ate Douma <at...@douma.nu>.
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 <fi...@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....@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org