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