Loaded? Nah, but indeed interesting. On the other hand I already got an answer that fits me (No, that is. Thanks Hans).
1. For example reusage of components from other systems, which is the idea of the concept with the Portlet spec. A portlet for Liferay would in that case work in Ofbiz too - or in any other portal that supports portlets. 2. Luckily, I hope that my customer wants to _not_ use their old portlets and instead make new portlet-style components in Flex (reusable almost everywhere), so I haven't thought about it yet. In worst case I have to. 3. I believe "redundancy in technology" is not a good thing, in Ofbiz there is a lot of redundancy alreday so I would not prefer to add more of that cake. In any case, the MyPortal is awaited from my point of view. 2009/2/11 David E Jones <[email protected]> > > My reply was somewhat of a loaded question, so I'm interested in Sven's > answer, but the idea behind a JSR-168 portlet assumes using certain other > tools like JSP that we simply don't use in OFBiz for very good reasons. > > I won't take the position that JSR-168/268 is not applicable to OFBiz, but > if we were to do anything with it we would need some specific things to go > after, like: > > 1. how (in detail) would OFBiz users benefit from JSR-168/268 support? for > example, what would they be able to do that they could not otherwise? > > 2. how would the JSR-168/268 specifications be implemented in OFBiz and > used internally in the project? or would they? > > 3. for cases of redundant technologies, what would we recommend to > developers as best practices for selecting between the different > technologies? > > -David > > >
