Endre St�lsvik wrote: >Thanks a lot for the quick reply! > >I do have some follow-up questions, though..! > > Huh... feared so :)
><snip> >| > >| >*) It seems like there are a couple of portlets present in the framework, >| >and it looks to me like in the documentation that these are supposed to >be >| >enough for you, except if you have really weird needs. Is this so? >Doesn't >| >one break MVC somewhat by using Velocity template language in addition to >| >the XML registiry stuff only to program new portlets? >| > >| > >| For the first part of the question, I'm not sure these portlets are >| really supposed to handle *all* your >| current needs (for example we're missing a standard POP3/IMAP inbox >| monitor portlet...) but they >| are supposed to give you a good start. > >OK.. But they are so tiny. They seems to only be made for aggregation of >internet data, and not to do any complex processing. > > Well... Turbine gives you many tools for developing a complete business application or at least business components. Jetspeed mainly adds aggregation on top of Turbine so Jetspeed itself does not really help a developer to build his business components it currently expects him to use Turbine framework. The Portlet component is effectively devised only for the rendering of content in an aggregated environment and does not imply or expect anything on the technology used to generate the content. You get to chose whatever tool/framework you best like. ><snip> >| >| >*) Is Jetspeed primarily designed to handle _viewing_ of enterprise data, >| >that is to extract data from the underlying source, and then present it >to >| >the user? It seems a bit like this because of the "we have made 5 >portlets >| >for you that handle almost everything you'd want" approach. What about >the >| >Enterprise Application Integration concept, where portlets should expose >| >some of an enterprise application's functionality? Or application-like >| >functionality, e.g. implement a group calendar system or a simple CRM >system >| >like www.salesforce.com, directly in the portal system? >| > >| > >| You can develop enterprise application integration portlet, it's just >| that we have not developped any. >| In any case, these kinds of development would more probably be done by a >| Jetspeed integrator >| although we could certainly host within the project some very generic >| ones like messaging, calendar, etc > >Thanks.. But I was more referring to the "programmability" of the framework. >If I want to make some _new_ portlets, not simply aggregating easy-to-fetch >internet concent, how do I do this? Am I supposed to be helped by the >VelocityPortlet thingy, or do I have to make my own portlets? If I must make >my own, how do I go about doing this? What if I'd like to make a hugly >complex application with TONS of Java code and ten different portlets >working in conjunction, each having ten different templates that they'd like >to juggle between? Where do I start, kind of?? > > Well, "portlets" basically provide views to your complex application. These views can be aggregated and personalized. So in a large app development like this, you would first develop your business components EJBs for example and then possibly use VelocityPortlet to develop your different views with a couple/dozen of Action classes controlling the overall app behavior. These Action classes will load the different business EJBs into the Velocity context (unless you have wrapped them into Turbine ApplicationTools and use the Turbine "pull" methodology). >| >| >*) The "instance" and "ref" types. What is this? Is it similar to the >| >"instance" stuff talked about in this document: >| > >| > > >>http://www-3.ibm.com/software/webservers/portal/doc/V41PortletDevelopmentGu >> >> >i >| >de.pdf > >Has anyone read that document?! ;) I try to sneak it into my every email, as >it seems to be a blastin' good portlet API! But I wonder how they're going >to handle "loadable modules", that is, point your configuration to a URL, >and then you will have another cool application with images, portlets and >everything "installed". Well, whatever.. > > Well, I've not read it completely yet but I do recognize many of the points we have discussed with the IBM team last year (with some differences though... :). It's a definitely better API than the current Jetspeed one. The current issue for us is not whether we're going to change it, it's whether we're going to implement the one found in "portlet_api" or wait for the JSR results. Also in all the cases, we need to think on how to provide migration path for the current API to the new one and possibly support backward compatibility... >| > >| >*) The actions. Are these supposed to take care of all your business >logic >| >needs? >| > >| > >| No. Actions are typically "controllers". They may sometimes be used to >| also implement the >| business logic, but Turbine would typically expect you to encapsulate >| all business logic within other classes >| (like Turbine AppplicationTools) all use the Action to populate the >| context provided to the template with >| the appropriate business objects (or use implicit context loading in >| case of Tools). > >My idea is that since VelocityPortlet is pretty stupid, then Actions would >have to be where I make my business logic, showing stuff into the context >from within the Action. But apparently not. So how do I configure that >loading, basically; which class do I extend, and where do I configure it to >run with my template? > > Best practice would be to wrap all your "model" classes in specific classes (for example Torque generated) then use your Action as "controller" to specify which business components to make available to the template at any given time and react to user input. The velocity portlet would be the "view" part proper. The VelocityPortlet itself is the just the code required to make this happen by tying an Action, a Portlet and a template. You can also use the "pull" methodology of Turbine and implicitely load your business objects in all the portlet contexts (configured in WEB-INF/conf/TurbineResources.properties) >| >| >*) The "addressing" of the portlets. The hello-velocity portlet has some >| >data that can be sent to it. >| > 1) Where is the action defined? How is this configured? >| > >| There's several way to invoke the action: >| - the Turbine way of specifying an "action" parameter in the portlet >| <form> tag. >| - the Jetspeed VelocityPortlet way of using an implicit action >| associated with a portlet through >| the registry. In this case, the FORM action must reference the calling >| portlet name or id. This >| is always done automatically when you use the Jetspeed provided link >| objects ($link, $jlink, etc... >| in the Velocity templates) > >Where do I get more information about these link objects? And may I change >that "implicit action" for my porlet? > > See WEB-INF/conf/TurbineResources.properties for the association between the context object name and class and the org.apache.jetspeed.util.template package for the tools themselves. >| >| > 2) How is it addressed? What if two portlets on the same screen had a >| >submit button? >| > >| > >| Since in each they specify the action to call and give a portlet >| identifier, it's not an issue. > >a) Hello Velocity doesn't seem to be doing this..? > > Yes it does. It uses the default Action tied to the portlet in its registry definition. >b) What about two hello velocities, then? Is this supported? > > Only since very recently when the portlet unique id was introduced that helps identity several instances of the same portlet. It may still be somewhat buggy. >| >Any help would be valued! Jetspeed isn't _that_ easy, with all the stuff >| >coming from both turbine and jetspeed.. ;-) >| > >| > >| > >| If you ever write a valuable documentation on Jetspeed from your study, >| you're welcome to >| contribute it back... :) > >I am afraid that it will be a more "review" tone over that document. I'd >just like to understand the concepts before writing it. But I will certainly >post the document (or a link, of course) to the list..! > > > I'm looking forwward to it then. -- Rapha�l Luta - [EMAIL PROTECTED] Professional Services Manager Vivendi Universal Networks - Paris -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
