Eric,
On 2/9/2012 8:18 PM, Eric Dalquist wrote:
I'm thinking #3 would be our best bet here. What does the import/export
data format for the DB backed DLM fragments look like?
It looks exactly like the format for defining a fragment in dlm.xml,
wrapped in a root element like this one:
<fragment-definition
xmlns:dlm="http://org.jasig.portal.layout.dlm.config";
script="classpath://org/jasig/portal/io/import-fragment-definition_v3-1.crn">
So the following would be a complete fragment-definition data file:
<fragment-definition
xmlns:dlm="http://org.jasig.portal.layout.dlm.config";
script="classpath://org/jasig/portal/io/import-fragment-definition_v3-1.crn">
<dlm:fragment name="Guests" ownerID="guest-lo" precedence="500">
<dlm:audience
evaluatorFactory="org.jasig.portal.layout.dlm.providers.GuestUserEvaluatorFactory"/>
</dlm:fragment>
</fragment-definition>
Is there any
chance we could move it into the JAXB Import/Export style and get an XSD
put together for the data file format?
https://wiki.jasig.org/pages/viewpage.action?pageId=42696914
I'm happy put my +1 behind that idea as a chosen road map, but I've got
a queue of tasks backed up that I'd like to take care of ASAP. I found
this issue, after all, digging into issues migrating user customizations
to DLM fragments on uP4. Correcting this issue isn't even the whole fix
-- it's a piece of the puzzle.
I'm thinking that since...
- (1) the current format is already familiar to adopters; and
- (2) layout management is expecting a significant re-architecture
we could move it to the JAXB/XSD model as a part of the process you
intend to launch "in about 2 months."
As for the plans for layout management, the goal is a revolutionary
change. What I would like to be doing after UW rolls out 4.0 in about 2
months is working on re-writing the user/profile/layout data model, dao
and service layers as JPA backed with a more component based layer on
top, similar to what we've done with the portlet data model and the
rendering pipeline in 3.0 and 4.0. I have a lot of ideas I've been
scratching down in notes and a big TODO to get them into the wiki but
some thoughts are:
- Ditching the internal concept of a layout == a XML document, XML DOMs
suck to work with in Java and have pretty significant performance issues
in many of our desired use cases. The new rendering pipeline wants a
StAX event stream and it would be VERY easy to generate a StAX stream
based on a strongly typed Layout/FolderNode/PortletNode tree structure.
- We can remove UP_PORTLET_ENTITY and related database tables and merge
the concept of an entity with a PortletNode in a user's layout. This
would simplify A LOT of the portlet registry code and reduce database IO
significantly as portlet entities are the most queried for object in
uPortal.
- There are a bunch of really good notes from the unconference around
the user - profile - layout relationships and how that should all
actually work, this would let us truly have multiple layouts for one
user based on the profile they are seeing.
Sounds great -- I believe these changes will benefit the platform.
drew
As you said, we don't want to stagnate incremental fixes and changes to
DLM but working on the DLM backing store and getting that moved into JPA
as our default config, flushing out the import/export for it, etc isn't
going to be wasted effort, it will just be less we have to do later.
Hope that helps,
-Eric
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
