Jen,
Thanks! Response inline...
Jen Bourey wrote:
> Just to clarify a few issues . . . (comments inline)
>
>
> On Mon, Oct 5, 2009 at 10:58 AM, Gary Weaver <
[hidden email]
> <mailto:
[hidden email]>> wrote:
>
> However, be aware that if you do have data stored for your portlet
> that
> links to uPortal data (like user IDs for example) that the portlet
> data
> might not be as isolated from the uPortal data as you might first
> think.
> If you do a restore (rollback) of uPortal data without also doing a
> restore (rollback) of every portlet's data, you could end up with data
> integrity issues if anything in the portlet's DB is referring to
> data in
> the other DB. And assuming that is correct, lifecycle separation might
> not be as easy as it sounds.
>
>
> First of all, I'd strongly caution anyone against linking portlet data
> directly against uPortal IDs. As of uPortal 3, most of the uPortal
> table IDs are unique, but are not necessarily consistent over time.
> Moving forward, the update process for uPortal requires use of the
> import/export tool, which preserves fnames, but not primary key IDs.
Just to note- I wasn't advocating tying anything to uPortal specific
implementation in portlet code. :) Just saying that any portlet-specific
user preference data stored in tables for portlets that aren't part of
uPortal have be tied back to the user.
If uPortal data is rolled back in the database, and those (recently
added) users go away, then any user preference data in tables belonging
to portlets that references those users (in any way) would be data not
be tied to the user to which it was intended. (And if you don't delete
that portlet's preferences data, another user with the same identifier
(even if not ID) got created, then that new user could have access to
the old user's preferences, and read their mail, etc. However, the fact
that portlets would even need their own tables for user-specific
preferences is just a symptom a deficiency in the portlet API's
inability to adequately solve the needs of storing user-specific portlet
configuration/data.)
Similarly, rolling back a database containing portlet preference data
without rolling back the uPortal database would mean missing preferences
for users that were there before (and therefore possibly unhappy users,
possibly).
Thanks for the point about uPortal possibly considering changing the way
that users are stored over time and how the import/export tool works.
That is good to know!
>
>
>
> As for the code being cross-platform, yes you should try not to
> rely on
> data that is not uPortal specific if you plan on running it in Liferay
> (etc.) in addition to uPortal, but from what I've seen most
> uPortal and
> Liferay (just as an example) portlets have portal-specific
> implementation (even those aspiring or even claiming to be JSR-168 or
> 286 compliant, like at least one that I saw on the Liferay side). For
> most people's custom portlets, it might not be worth the time to write
> something that is truly non-portal-implementation specific. In the
> end,
> there would be many UI issues to work out with custom portlets if they
> switched to a new portal implementation in their custom portlets, in
> addition to those other things in the code that are
> portal-implementation specific (unless you constantly test against
> newer
> versions of the portals like your team probably does). I'm not saying
> that people should just give up and not write portlets that work on
> multiple platforms, but I'm just saying that I think you and your team
> are probably one of the few doing it (to my dismay and I'm sure
> others'
> as well- but that's life).
>
>
> Most Jasig portlets take the JSR-168 spec seriously and do not have
> any portal-specific code. I know that a number of Jasig portlets
> successfully run in both Pluto and in Liferay, and some are being used
> in Liferay in production. Portlets may occasionally require
> particular JavaScript frameworks, but these are generally well-known
> and documented public libraries that may already exist in a different
> portal. If they don't, they're generally easy to add. Of course,
> you're correct that Liferay portlets don't necessarily run in other
> portal containers.
My beef is less with whether they will run or not but how they will look
once they are there, although I'm pretty sure that I've seen portlets on
the Liferay side that have Liferay specific code as you mentioned. If
you deploy a portlet and then have to manually set styles for a bunch of
controls and containers within the portlet in every skin you have, that
makes it a lot less friendly to portal admins (that usually aren't
experts in CSS styling much less specificity rules, etc.) to implement,
and it deters portlet skins from being shared among even the uPortal
community to any measurable extent. While uPortal supports the PLT.C
styles, not only are the styles in JSR-168 inadequate in
number/kind/description of use, but there is no clear and consistent way
either indicated in the JSR-168 spec nor in past discussion for a set of
standards that could be used to define styles outside of PLT.C styles
such that default CSS could be used in the portlets that could easily be
overriden in skins in a consistent way. I am aware that Fluid and those
in Jasig helping with uP have contributed much to try to eliminate this
issue as much as possible, but the fact is that styling and skinning
still has to be one of the biggest impediments (beyond things just "not
working" sometimes obviously ;) ) to the sharing of portlets. I for one
was much less enthused about developing portlets for the community when
I found out how much of a mess that was, and that it wasn't getting any
better with JSR-286 (in fact, if I remember correctly, PLT.C got worse-
in fact stuff like JSR-286 PLT.C.4 and PLT.C.5 having two different
classes for the same parts of tables just shows how much they considered
the importance of CSS, which is not something you can overlook in 2009
like you could in the early-mid 2000's).
Thanks!
Gary
---
You are currently subscribed to
[hidden email] as:
[hidden email]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-user
smime.p7s (4K) 
