El viernes, 24 octu, 2003, a las 22:16 Europe/Madrid, Weaver, Scott escribió:
Wow. So you are saying that if you want to do MVC style development that
you _should not_ use Jetspeed 2? Ok.
No. The MVC model is not provided by the portal, it is not the domain of the portal! This is the current problem with J1, it is all bundled together, which handcuffs the end developer from doing what she/he really wants to plus I t generally makes everything a mess.
Portlet applications are separate from the portal. Portlets SHOULD NOT rely on the portal for anything outside of what the spec provides. I don't think it wise for us to try and recreate a web application framework when there are so many out there.
We could eventually write a specialized MVC framework like the current one in J1 that could hook directly into the Portal's functionality. However, that is not as important right now. Plus it would make the portlets non-portable.
Agreed. Just to point that a specialized MVC framework like this one can be kept as a subproject of jetspeed2, specially if we have portlet applications depending heavily on it that will be ported from jetspeed 1.
Also, if we wanted to publish common services for portlets to consume it would have to be done in manner were those commons services can easily be ported to other containers. I think this type of functionality is desirable, but again it is not at the top of the > list.
This is an interesting area. This is, IMO, where turbine shines in comparison with other webapp frameworks.
What is the domain of the portal? - profiling - personalization - navigation - security - page aggregation - request dispatching - standardized presentation through themes and skinning - handling WSRP based portlets - (possibly) inter-portlet communication
You are more than welcome to expand on any/all of these. By all means submit formal proposals and I will commit them to the CVS.
+1
Regards, *================================* | Scott T Weaver | | <[EMAIL PROTECTED]> | | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | *================================*
-----Original Message----- From: Todd Kuebler [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2003 3:14 PM To: Jetspeed Developers List Subject: Re: Jetspeed2 and MVC idea
Wow. So you are saying that if you want to do MVC style development that
you _should not_ use Jetspeed 2? Ok.
-tk
At 08:43 PM 10/23/2003 -0700, David Le Strat wrote:Todd,
What about using Struts or JSF as your Portlet MVC model? Looks like the Struts team is working with a Struts version compatible with JSR168 and the final release of JSF should be compatible as well.
Regards,
David.
--- Todd Kuebler <[EMAIL PROTECTED]> wrote:---------------------------------------------------------------------
I continue to believe that the Portlet idea in practice should simply implement the controller paradigm of the MVC instead of being some class that needs extending by the typical web developer just to create a html fragment. Just like servlets are best served by something like Struts, I believe portlets are best served by something like the MVCPorlet idea. There should be a config file that ties actions/events to views, which the controller (portlet) uses to render it's fragment.
Maybe the J2 core doesn't deal with that, only providing a container for JSR 168, but as a portal implementation it will have to deal with this idea sooner or later to reach maturity imho since web applications are almost universally seeking the MVC paradigm going forward.
Thoughts?
%regards -tk
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
