j2-admin refactoring in 2.2

[David Sean Taylor <da...@bluesunrise.com>]

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

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
2. Extensibility - we need an easy way for users to customize and  
extend the admin portlets
     where we have done a decent job with this in portlets like the  
User Details, having a large set of preferences,
     I recently went through extending the User Registration portlet  
and kept running into hard-coded features
     All hard-coding has to go and we need to better consider how  
users can easily extend the portlets
     I am hoping leveraging Wicket can help here
3. Document features in help mode, about mode. The admin portlets are  
not well documented. Lets not neglect that responsibility this time  
around.
4. support edit_defaults in all portlets
5. Notifications - not all, but some portlets are not properly hooked  
into notifications (such as deployment events -> PAM portlet)
     or the profiler portlet is not notified of profiler changes made  
during an import.
6. Software Design - lets do a prototype first. then check it in for  
review and comment, and iteratively design from there
7. Web Design - I believe the portlets should be skinned with a new  
decorator to introduce a new, modernized feel to these web1.0 portlets
8. Web 2.0 - make use of any web 2.0 features available in Wicket  
(again I plead ignorance to these features)
9. leverage the Jetspeed AJAX API where applicable

Finally, I want to move the j2-admin application out of Jetspeed and  
into a new Portals project, Portals Applications
I know that j2-admin can only be used by Jetspeed, but I am of the  
opinion that it should be released on its on release cycle

-- 
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194




Re: j2-admin refactoring in 2.2

[Ate Douma <at...@douma.nu>]

Hi guys,

Sorry for responding so late but I'm away in Reading, UK, for a JSR-301 F2F meeting since Monday.
As I had the bad luck of a non-functional wireless network card in my laptop I've been "blind" until yesterday evening, and during the day I don't have a 
connection either at the meeting place.

(FYI: Yesterday evening I didn't have time to properly process my email either as I had to figure out Jetspeed 2.1.3 deployment instructions on JBoss 4.2.1 for 
a client. I got that working nicely and I'll put it up on a WIKI page soon).

Anyway, I'm back online now and have provided a lot of comments on this below.

I'll fly back home tomorrow evening and will be back in d2d business on Friday.

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 that a first prototype is best.
+1

> 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
Not much we can do about that at this time.
Pluto 2.0 trunk isn't "ready" enough yet as a properly compliant JSR-286 container.
But it'll get there sooner or later, also depending on how much time we'll be able to put in to help out with that.
Actually, investigating what is going to be required to migrate to Pluto 2.0 (while it isn't fully "frozen" on SPI etc.) might be something to consider.
There will certainly be issues, incompatibilities and other annoyances which we can help identify and potentially "fix" before Pluto 2.0 is released so our 
migration path will be somewhat easier and integration can be done better / natively.
But this is a different subject we might want to discuss in a separate thread...

With regards to using JSR-286 coordination features (events, public render parameters), there is no support for that in Wicket yet, mainly because of lack of 
time on my side and JSR-286 not yet formally released and available to build against. But it definitely is something high on my TODO list, and with the recent 
Pluto 2.0 trunk merge there now is a codebase to build against.

For the time being, my preference would be to prototype using a single Wicket portlet with both a browser and details panel component.
As Wicket really is component based, defining these archetype components as "standalone" panels, we can start out with integrating them initially on one Wicket 
Page. Once JSR-286 support has arrived, it should be possible to simply split these up in two different Wicket pages, served by different portlet (instances).

Also, these archetype browser and details panel components really should be written such that they are easily extendable so we can then reuse them for many 
different portlets, User/Role/Group management and maybe even others too.

> 
> 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.
I agree Role Manager or Group Manager are good starting points, Vivek indicated though he's interested in starting with the User Manager.
It might actually be a good idea to start with 2 portlets as that will allow as well force us to create reusable and extendable archetype components.
Reuse and extendability in my view are the key architectural features we do need to deliver.

As Dennis also indicated he wanted to help out, I propose Dennis and I start working together on a Role Manager portlet, and Vivek could start with the User 
Manager. Of course, we first will need to flesh out our common requirements and discuss and come up with a design for it.
Everyone interested is of course more than welcome to join forces and help out, with discussions, investigating requirements, design, review, code, patches, etc.

> 
> 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.
Although I'm a bit biased of course as Wicket committer and primarily behind its portlet support, I'd like to provide my view and preference to use Wicket.

JSF indeed is the standard and there are many rich components out there. I definitely think JSF will be (not is) a valid framework for portlet development which 
explains my interest and role in the JSR-301 EG which is all about that.
But the current JSF (1.2) spec and neither the different implementation (MyFaces, Sun RI) are currently very good at supporting portlet development and behavior 
isn't always quite what you'd expect and need. That is why JSR-301 now is defining a JSF Portlet Bridge spec for, to cover the defiances and define the proper 
behavior in a portlet environment. That spec isn't ready yet, although a JSR-168 Bridge spec review probably will be soon be ready.
The JSR-301 Bridge though isn't targeted to developers but to the JSF core implementors, to allow them to provide a consistent and standard implementation.
At any rate, proper portlet support by existing JSF components is variant to say the least, and often very much tied to specific portals (Jetspeed not being one 
of the main players in this respect).
But still, it is/should hopefully be doable to "properly" rewrite the j2-admin portlets in JSF too.
That still doesn't make it the best framework to use though.
My own experiences with JSF hasn't been very favorable, I personally don't very much like the "model" and architecture behind it and requires too much 
"plumbing" to my taste.

Using Wicket on the other hand has been very refreshing. The fact that you (hardly) need any xml based configuration, everything is Java based and refactoring 
and extending functionality really is a breeze. And the very clean HTML *only* markup usage allows true separation of tasks: UI design now can fully be handled 
by proper designers, no need for the developers to look after. That alone already "sold" me to Wicket as I (and in my experience most Java developers) am very 
bad at drafting up a nice and good UI design.

And the extendability of Wicket is I think unmatched by almost any other framework, including JSF. Package your component in a jar, including (example/base) 
HTML markup and simply start using *or* extending it to your taste for your own project or application.

Finally, although Wicket is still young, it already provides a wealth of base and reusable components. Its nothing compared to what is available in the JSF 
market (some costing quite a lot of $$$), but for our requirements I think its already more than we need right now. Ajax support for instance is fully 
integrated in the framework and needs zero javascript coding. Furthermore, Wicket transparently provides a server-side fallback mechanism when the client 
doesn't support/allow javascript execution, so your application still will work as expected! Now that is a very cool feature I think (and very important for 
organizations like the Dutch government which demands support for non-javascript enabled clients).

For anyone yet unfamiliar but interested to see some cool Wicket examples running: http://www.wicketstuff.org/wicket13
NB: that default Wicket examples application can also be deployed and runs very nicely in Jetspeed 2.1.3 :)

> 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?
I'm too tired right now to dive into this and lookup a simple example, but the wicket wiki contains a wealth of examples and instructions for doing so, see:
   http://cwiki.apache.org/WICKET/reference-library.html

NB: I seriously advise anyone not 100% familiar with Wicket (I'm not) to buy and read "Wicket In Action".
Its not out yet but you can buy MEAP access and most of the book is now finished and available for download (once you bought it):
   http://www.manning.com/dashorst/

It *really* is a very good book and it'll bring you up to speed with Wicket, and especially the more/most essential "Model" in the framework. Everyone needs to 
at least read that chapter (5. Understanding models).

> 
> 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
Definitely, and this really comes down to defining and using a good "detachable model" in Wicket terminology.
Furthermore, this most likely goes to the underlying UserManager api which currently isn't very good at supporting and providing subset query results.
On the UI side, Wicket has some very nice "paging" table/tree components which we can leverage for this.

> 2. Extensibility - we need an easy way for users to customize and extend 
> the admin portlets
>     where we have done a decent job with this in portlets like the User 
> Details, having a large set of preferences,
>     I recently went through extending the User Registration portlet and 
> kept running into hard-coded features
>     All hard-coding has to go and we need to better consider how users 
> can easily extend the portlets
>     I am hoping leveraging Wicket can help here
This definitely needs to be one of our primary goals from the outset, so +1

> 3. Document features in help mode, about mode. The admin portlets are 
> not well documented. Lets not neglect that responsibility this time around.
+1

> 4. support edit_defaults in all portlets
+1

> 5. Notifications - not all, but some portlets are not properly hooked 
> into notifications (such as deployment events -> PAM portlet)
>     or the profiler portlet is not notified of profiler changes made 
> during an import. 
Although I haven't given this much thought yet, we could provide some kind of listeners support in our Wicket detachable model(s).
By designing for /invalidate/flush/refresh etc. events and then hook that up to some kind of event dispatch mechanism this should be quite doable.
And once JSR-286 comes around, we can then leverage proper Portlet Events to drive this.

> 6. Software Design - lets do a prototype first. then check it in for 
> review and comment, and iteratively design from there
+1

> 7. Web Design - I believe the portlets should be skinned with a new 
> decorator to introduce a new, modernized feel to these web1.0 portlets
+1
We do have a UI designer at the company, I can investigate if we can "borrow" him a bit to come up with a slick new UI.

> 8. Web 2.0 - make use of any web 2.0 features available in Wicket (again 
> I plead ignorance to these features)
I propose we use Wicket Ajax support as much as possible, especially as Wicket provides server-side fallback when not available on the client.

> 9. leverage the Jetspeed AJAX API where applicable
That might not be so trivial to do I think, and I'm not sure its the right way to go either.
I do see the benefit of leverage the Jetspeed AJAX API as "framework independent" API, but Wicket build in Ajax support really is self contained, e.g. only 
usable for interacting with Wicket components and models. That doesn't mean we cannot write and emit our own Ajax interactions for Wicket, but leveraging the 
Jetspeed AJAX API from the client will not be "connected" to the Wicket components and thus synchronizing their state with the underlying (changed) Jetspeed 
data won't be trivial and probably require extra roundtrips and more complex code anyway.
In my view, the idea would be to use Wicket models to hook up on the Jetspeed services directly. Technically, I don't think we need nor should add another 
abstraction layer between that.

> 
> Finally, I want to move the j2-admin application out of Jetspeed and 
> into a new Portals project, Portals Applications
> I know that j2-admin can only be used by Jetspeed, but I am of the 
> opinion that it should be released on its on release cycle
Yes, no, yes.
We've discussed this before, and I'm all for a new Portals Applications project.
And I also agree we need to move j2-admin (and probably jetspeed-layouts) out of main Jetspeed tree and give them (potentially) their own release cycle.

But, in my view the scope of "Portals Applications" should be for "generic", e.g. not Jetspeed only/specific apps, like our rss application or the Bridges 
example apps (JPetstore etc.)

For Jetspeed specific apps like j2-admin and jetspeed-layouts, I think they will always be tied to a specific version (or range) of Jetspeed, which makes it 
likely they will follow its release cycle too. Maybe (and there is the benefit), intermediate update/fix releases of these apps might follow independently, but 
once a new Jetspeed release is done, most likely we'll need/want to release updated/enhanced j2-admin and jetspeed-layouts too.
Anyway, as I said, I'm all for moving these apps out of the core jetspeed trunk, so they can be checked out and maintained more or less independently.

To support this, we could restructure our current jetspeed svn source tree as follows:

\jetspeed-2
   \j2-admin
      \trunk
      \tags
      \branches
   \jetspeed-layouts
      \trunk
      \tags
      \branches
   \portal
      \trunk
         \jetspeed-api
         \jetspeed-common
         \jetspeed-portal-resources
         \components
         \maven
         \assembly
            (different portal profiles, like demo, base, tomcat, geronimo, etc.)
         \...
      \tags
      \branches
   \... (maybe site/docs/tutorial etc.)

WDYT?

One important task to handle splitting up our codebase, however we do it, is setting up the required JIRA project(s) for it, as we use that as main/driving tool 
for managing releases. Too bad though JIRA still cannot handle "subprojects" with their own release versioning.

Regards,

Ate

> 
> -- 
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com <ma...@bluesunrise.com>
> [office] +01 707 773-4646
> [mobile] +01 707 529 9194
> 
> 
> 


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

[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

[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

[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

Re: j2-admin refactoring in 2.2

[Woonsan Ko <wo...@yahoo.com>]

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

[Vivek Kumar <fi...@gmail.com>]

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

Re: j2-admin refactoring in 2.2

[Dennis Dam <d....@hippo.nl>]

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

Re: j2-admin refactoring in 2.2

[David Sean Taylor <da...@bluesunrise.com>]

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


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

[Dennis Dam <d....@hippo.nl>]

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

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

> 2. Extensibility - we need an easy way for users to customize and 
> extend the admin portlets
>     where we have done a decent job with this in portlets like the 
> User Details, having a large set of preferences,
>     I recently went through extending the User Registration portlet 
> and kept running into hard-coded features
>     All hard-coding has to go and we need to better consider how users 
> can easily extend the portlets
>     I am hoping leveraging Wicket can help here
> 3. Document features in help mode, about mode. The admin portlets are 
> not well documented. Lets not neglect that responsibility this time 
> around.
> 4. support edit_defaults in all portlets
> 5. Notifications - not all, but some portlets are not properly hooked 
> into notifications (such as deployment events -> PAM portlet)
>     or the profiler portlet is not notified of profiler changes made 
> during an import. 
> 6. Software Design - lets do a prototype first. then check it in for 
> review and comment, and iteratively design from there
> 7. Web Design - I believe the portlets should be skinned with a new 
> decorator to introduce a new, modernized feel to these web1.0 portlets
> 8. Web 2.0 - make use of any web 2.0 features available in Wicket 
> (again I plead ignorance to these features)
> 9. leverage the Jetspeed AJAX API where applicable
>
> Finally, I want to move the j2-admin application out of Jetspeed and 
> into a new Portals project, Portals Applications
> I know that j2-admin can only be used by Jetspeed, but I am of the 
> opinion that it should be released on its on release cycle
>
> -- 
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com <ma...@bluesunrise.com>
> [office] +01 707 773-4646
> [mobile] +01 707 529 9194
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org