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