A while back while working with a client, we began to pursue developing a
portal framework on top of Struts. I have the original work we began with
and have been continuing to work with it since when I have time.
The basic design consists of a workbench. The workbench consists of
benches(novel huh?;). Each bench contains modules. The modules can be
thought of as the individual portals.
We ran into some headaches with some architecture and design questions
including the layout mechanism for the benches. Lately, I have been feeling
like Tiles could fulfill this. We also had no vehicle for user customization
perse. The benches were predefined for all users as were the modules. My
hope was once that was working, we could tackle the customization portion.
Anyways, I would be willing to let folks take a look and perhaps expand on
it if there was interest.
Thanks,
Scott
IBM
----- Original Message -----
From: "Struts Newsgroup" <@[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 10, 2002 12:10 PM
Subject: Re: New API specification
> Subject: Re: New API specification
> From: Vic Cekvenich <[EMAIL PROTECTED]>
> ===
> CRUD is a DB term. It stands for Create (Insert), Read (Select), Update
> and Delete. Struts does a lot, but not CRUD. RowSet does nice CRUD.
>
> Master Detail - Say you have a list of customers that have invoice.
> Customers are the master record in a join, invoices are detail.
>
> Navigation - You should have one place to change your site navigation,
> no matter how many pages you have. I use "Struts-menu" from Ted's site.
>
> Audit - Some users need to track how many displays / exposures and click
> troughs you have of something. A collection like a linked list can Q it
up.
>
> RSS - Is a way to display content. Basically I create a table with a
> description, image, and text. It can be feed externally by RSS
> Syndicated content providers. But mostly people internally write an
> article in a DB, and a page just displays the text in the DB.
>
> hth (hope this helps)
> Ciao
> Vic
>
>
>
> Thomas Eichberger wrote:
>
> > Hi Vic,
> >
> > hm, could you please help me with some details, I'm not sure, what you
> > mean by some of the following terms. I also would like to know HOW you
> > implemented those things or what tools you need (I'm very curious):
> >
> > CRUD - what does that stand for (I'm not completely stupid, I just
> > missed this one;-)
> >
> > Master/Detail processing
> >
> > navigation
> >
> > collection for audit tracking
> >
> > RSS
> >
> >
> > Would be very nice from you to supply some information...
> >
> > Ciao
> >
> > Thomas
> >
> >
> >
> > At 08:25 10.01.2002 -0800, you wrote:
> >
> >> Subject: Re: New API specification
> >> From: Vic Cekvenich <[EMAIL PROTECTED]>
> >> ===
> >> Hello Sandra,
> >> In general, I would say the less technology applied in the framework
the
> >> better, but still make the framework do the heavy pulling. 80/20 staves
> >> it should be 20 % of things you use 80% of time (so not everything). I
> >> think it is more flexible.
> >>
> >> I think that minimum should be: Struts MVC, container security, CRUD,
> >> Master/Detail processing, navigation, a collection for audit tracking,
> >> RSS for displaying content, (client side) XSLT and Tiles and not much
> >> more.
> >>
> >> Otherwise it is a complex design that is a lawnmower that is also a
> >> submarine and a bulldozer. Elegance is key.
> >> (Ex: Anyone can build a bridge using lots of material and time. However
> >> an engineer can figure out how thin a cable can be and meet the
> >> requirements)
> >> Jet speed is to big to be productive, or to maintain and it takes a
> >> while to learn. Struts is just MVC, that is pretty much it. I just add
> >> RowSet for a simple CRUD and done.
> >> I used to think complex is more sophisticated, but found out that less
> >> is more.
> >>
> >> my 2 c.
> >> Vic
> >>
> >> ps: I will hold a Struts Class during the JavaOne, so I will have a
room
> >> that holds 60 or so. Do we want to set up a 4 hour Struts conference,
> >> say on Thursday, have a few of us present (you, Ted, me, etc. for 30
> >> minutes each?)
> >>
> >> ps 2:
> >> For the Struts group, here is a RowSet snippet CRUD that auto updates,
> >> inserts and deletes, regardless of the number and type of columns. I
> >> just put it in my base FromValidatorBean. Based on a select String this
> >> knows how to update. Simple enough?
> >>
> >> update(){try{
> >>
> >> dbCon(); // my method to connect to connection pool
> >> _crs.updateRow(); // rowSet update. _crs is what geters and
> >> setters go against
> >> _crs.acceptChanges(getCon());
> >> dbDisCon();
> >>
> >> } catch (Exception e) { procE(this,e);} // my debug method
> >> return 0;}
> >>
> >>
> >>
> >>
> >> Sandra Cann wrote:
> >>
> >> > I was getting caught up on the Jetspeed list and just read the thread
> >> > discussing integrating different frameworks including Struts with
> >> Jetspeed.
> >> > I would be interested in hearing from people interested in using
> >> Jetspeed
> >> > with Struts and perhaps doing some collaboration on this effort.
> >> >
> >> > Sandra Cann
> >> > [EMAIL PROTECTED]
> >> >
> >> >
> >> >>-----Original Message-----
> >> >>From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> >> >>Sent: Sunday, December 23, 2001 4:00 PM
> >> >>To: 'Jetspeed Developers List'
> >> >>Subject: RE: New API specification
> >> >>
> >> >>
> >> >>
> >> >>>De: Thomas Schaeck [mailto:[EMAIL PROTECTED]]
> >> >>>Enviado el: domingo 23 de diciembre de 2001 11:46
> >> >>>
> >> >>>A portlet container needs not be tied to any particular
> >> >>>framework, e.g. an
> >> >>>architecture like this can avoid any dependency of a portlet
container
> >> >>>implementation to the framework on which a portal that uses
> >> >>>the container
> >> >>>is built:
> >> >>>
> >> >>>
> >> >>Agreed, i was confusing the terms, talking about the mix of portlet
> >> >>container and portal implementation..
> >> >>
> >> >>
> >> >>> Portal | Portlet Runtime Env
> >> >>>+------+ +-------+ | +---------+ +-------+
> >> >>>|+------+ |Portlet| | |Portlet | |+-------+
> >> >>>+|Portal|<->|Invoker|<-|->|Container|<->+|Portlet|+
> >> >>> +------+| | I/F | | | | +-------+|
> >> >>> +------+ +-------+ | +---------+ +-------+
> >> >>>
> >> >>>The portal could be based on any framework, be it Struts, Turbine,
or
> >> >>>something else. Also, many different portals may use the same
> >> >>>comtainer.
> >> >>>
> >> >>>
> >> >>JetSpeed 2 will be a the sum of 3 things instead of 2:
> >> >>
> >> >>1) Portlet Container and Portlet Specs..
> >> >>
> >> >>2) A Portlet Container Implementation, independent of any framework
> >> >>
> >> >>3) A Portal implementation, framework dependant..
> >> >>
> >> >>
> >> >>
> >> >>>Typically, the portal needs to call portlets for purposes such as
> >> >>>dispatching events (e.g. action events or window events) to
> >> >>>portlets so
> >> >>>they can react on those events and for obtaining markup from
> >> >>>portlets. The
> >> >>>
> >> >>
> >> >>Which is your idea of the methods to transmit markup between layers?
> >> >>like it's now? adding SAX to the mix?
> >> >>
> >> >>
> >> >>>PortletInvoker interface to be used by portal implementations
> >> >>>for invoking
> >> >>>portlets needs to have corresponding methods that are
> >> >>>additionally taking
> >> >>>portlet identifiers and portlet instance identifiers as
> >> >>>parameters that
> >> >>>identify the target portlets to invoke.
> >> >>>
> >> >>>Best regards,
> >> >>>
> >> >>>Thomas
> >> >>>
> >> >>>
> >> >>Many Thanks .. for jump in and the brief clarification.. still
> >> >>learning.. I need urgently to read the portlet spec present in the
CVS
> >> >>;)
> >> >>
> >> >>
> >> >>Saludos ,
> >> >>Ignacio J. Ortega
> >> >>
> >> >>
> >> >>
> >> >>--
> >> >>To unsubscribe, e-mail:
> >> >>
> >> > <mailto:[EMAIL PROTECTED]>
> >> > For additional commands, e-mail:
> >> > <mailto:[EMAIL PROTECTED]>
> >> >
> >> >
> >> > --
> >> > To unsubscribe, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >> > For additional commands, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >> >
> >>
> >>
> >> --
> >> To unsubscribe, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >> For additional commands, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >
> >
> > Thomas Eichberger - Software und Schulungen - Spezialisiert auf Java
> > A-1230 WIEN, Endresstr. 103/3
> > phone/box/fax: 01-8861685 Web: www.java.at E-Mail: [EMAIL PROTECTED]
> > "Every job is a self-portrait of the person who did it. Autograph yours
> > with excellence."
> > "For every complex question there is an answer that is clear, simple and
> > wrong."
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
