On 2/8/2012 7:05 PM, Eric Dalquist wrote:
Hrm, good catch, I'm on vacation for a few days but I'll see if I can
collect my thoughts on this and get a good reply posted tomorrow.
Looking forward to reading it.
One question that comes to mind quickly is this: what is the nature of
our aspirations for improving layout management? Are they evolutionary
or revolutionary?
I believe switching to the JPA fragments is a solid evolutionary move.
It would be one step in a process of slowly making the existing DLM code
reflect our more contemporary vision of what it should be.
I believe an evolutionary approach with DLM it totally doable, but given
where it's at I would not be surprised to hear that a complete re-do is
under consideration.
*IF* the DLM code is actually queued up for imminent replacement, then
incremental improvements in the old code are less attractive. But of
course it's dangerous to hold out the promise of a revolutionary
solution: no one works on the old code because it's "going away," while
no one works on the new code either.
drew
On 2/9/12 12:43 AM, Drew Wills wrote:
Hey folks,
How much do we care about the fact that the uP default XML data is
divided into 3 directories?
- required_entities
- default_entities
- quickstart_entities
I ask because it's come to my attention that there are currently some
features that aren't working correctly *in part* because the entities
aren't going in all at once -- or perhaps because of the way in which
they're divided.
Here's how it goes...
> uP begins importing required_entities
> it imports the entity types, stylesheets, users, portlet types, and
profiles found therein
> then it imports the defaultTemplateUser & system layouts, BUT
> in doing that it hits DLM code, which causes the DLM subsystem to
bootstrap
> in bootstrapping DLM reads dlm.xml and tries to evaluate the objects
refers to
> dlm.xml refers to objects in default_entities (specifically groups),
which haven't been imported yet
> The DLM subsystem can't do it's job later because it's state doesn't
reflect (intended) reality
I see a few ways to deal with this issue:
- (1) re-combine the three entity folders to eliminate this whole
class of problems
- (2) cherry pick items from default & quickstart entities (and put
them in required) to solve the problems we actually observe
- (3) Switch to the JPA/Hibernate ConfigurationLoader implementation
(originally sponsored by Pearson), which doesn't bootstrap based on
dlm.xml at all (it recognizes changes to fragment defs in real time);
also (possibly) deprecate the LegacyConfigurationLoader at the same time
I think I like #3, which also has the advantage of allowing you to
add/remove fragments -- or change their audiences -- while the portal
is up.
Please share thoughts.
cheers,
drew wills
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
