On the URIs issue, have you played with the URIs in uP4 yet? We are VERY close to what you want and with a the underlying layout refactoring we can add things like url safe fnames. Right now if someone wanted to spend about two days we could likely remove the layout node id from the fname.nodeId syntax bit of the URL for 95% of the URLs and with another 2 days we could use the tab simple-name support that Drew added a while back in place of the nodeId for the folder name part of the URL.
Since I know others are interested as well I'll start getting the layout management redesign notes into the wiki next week so we have a few months to talk about them before any big work starts.
-Eric On 2/10/12 4:09 AM, Carroll, Tim wrote:
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) realityI 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
smime.p7s
Description: S/MIME Cryptographic Signature
