concerning layout management... i've been collecting some thoughts about this over the years as well. i'd like to see us consider a model where layout elements (folders, portlet-publications, portlet-subscriptions) are all non-typed objects stored in a single table with a unique identifier that could be used to resolve a URL endpoint, and the hierarchal or tagged (or otherwise) relationships among those objects is meta-data.
this would definitely be categorized as revolutionary and would require some outside-the-box thinking to achieve, but i believe it would help solve some of the fundamental issues concerning intuitive user friendly/readable/hackable/bookmarkable URIs to portal/portlet content. tc On Feb 9, 2012, at 10: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? 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 > > 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. > > 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
