The nodeIds don't really have anything to do with the database, though the data model is dirty and uses that id for both a DB key and a node identifier. The reason those nodeIds exist and can't just change is DLM. DLM creates compound node ids that look like u2l3n4 which translates into "nodeId 4 of layoutId 3 for userId 2". These are then used in the modifications that users make to their layouts like "u2l3n4 moved under u2l3n8" so these modifications reference nodes from the fragment layouts. This is a design constraint of DLM and isn't easily removed from the current data structure. When you export the data you need some way in user X's layout file to reference specific nodes from template user Y's layout file. Numeric IDs are about the easiest option to deal with. Without them if you modify the fragment layout how will the system know that was used to be node 8 is actually now node 9 and ensure users see the expected content.
On Fri, Jul 25, 2014 at 3:48 PM, Andrew Petro <[email protected]> wrote: > Yes, a solution that eliminates node identifiers in the import/export > XML would be even better. I considered being against this idea on the > basis that that's what we should actually be working on. Then I figured > let's take a bit of progress where we can get it. :) > > > Andrew > > > > > ------------------------------ > *From:* [email protected] < > [email protected]> on behalf of Anthony Colebourne < > [email protected]> > *Sent:* Friday, July 25, 2014 5:06 PM > *To:* [email protected] > *Subject:* [uportal-dev] Re: [uportal-dev] sequential IDs in > layout-fragment.xml files contributing to commit noise > > Hi, > > I always thought the long term aim was to move away from serializing the > xml across database rows? > > This solution would probably work well for a long time, but if we don't > like id's then shouldn't we try to eliminate them? > > Anthony. > > Sent from my HTC > > ----- Reply message ----- > From: "Andrew Petro" <[email protected]> > To: <[email protected]> > Subject: [uportal-dev] sequential IDs in layout-fragment.xml files > contributing to commit noise > Date: Fri, Jul 25, 2014 22:46 > > +1, especially as base-10-ized by Dalquist's suggestion. > > I'd only expect to see this sort of change come into master towards 4.2 > and not come into a patches branch. > > I'd love to see the convention documented in a README.md co-located with > the layout-fragment.xml files it describes, and I'd love to see an > automated convention-adherence-check included in the product test suite and > executed by travis-ci so as to avoid forgetting about the convention and > regressing in the product. > > PS: This reminds me of conventions about Applesoft Basic line numbers. > > > > On Fri, Jul 25, 2014 at 2:56 PM, James Wennmacher <[email protected]> > wrote: > >> That's a good idea. Even simpler. Thanks! >> >> James Wennmacher - Unicon480.558.2420 >> >> On 07/25/2014 12:36 PM, Eric Dalquist wrote: >> >> I'd go even further and start at 100 instead of 10 to give you more >> space since most layouts only have 3 levels >> >> >> - 1 >> - 100 >> - 110 >> - 120 >> - 200 >> - 210 >> - 220 >> >> >> >> >> On Fri, Jul 25, 2014 at 10:00 AM, James Wennmacher < >> [email protected]> wrote: >> >>> Inspired by https://github.com/Jasig/uPortal/pull/392/files#r15399346, >>> I'll state that I've found it annoying that we tend to have sequential #s >>> in the IDs in the layout-fragment.xml files. I propose we adopt a >>> numbering convention that spaces the IDs out so changes to a file generally >>> don't incorporate a lot of unneeded noise of renumbering IDs throughout the >>> rest of the xml file. >>> >>> My proposal is: >>> >>> - root folder has an ID of 1 >>> - folders under root are spaced 30 apart, first one starting with ID=10 >>> to allow for 2 or 3 columns >>> - column folders are spaced 10 apart starting with the next sequential # >>> - portlets just take the next available sequence number under their >>> corresponding folder >>> >>> so something like (contents abbreviated to show concept) >>> >>> <layout> >>> <folder ID="s1"> >>> <folder ID="s10" type="page-top"> >>> <channel fname="dynamic-respondr-skin" ID="n11"/> >>> <channel fname="fragment-admin-exit" ID="n12"/> >>> </folder> >>> <folder ID="s40" type="customize"> >>> <channel fname="personalization-gallery"ID="n41"/> >>> </folder> >>> <folder ID="s70" name="Welcome" type="regular" > >>> <folder ID="s71" name="Column" type="regular"> >>> <channel fname="email-preview-demo" ID="n72"> >>> <channel fname="weather" ID="n73"/> >>> <channel fname="pbookmarks" ID="n74"/> >>> </folder> >>> <folder ID="s80" name="Column" type="regular"> >>> <channel fname="calendar" ID="n81"/> >>> </folder> >>> <folder ID="s90" name="Column" type="regular"> >>> <channel fname="other-calendar" ID="n91"/> >>> </folder> >>> </folder> >>> </folder> >>> </layout> >>> >>> This would reduce time when making manual layout changes, and reduce the >>> noise in some of the commits. We could forgo sequential numbering >>> altogether, but I think something like this would strike a reasonable >>> balance to make it easier to avoid duplicating ID #s, and it would reduce >>> the confusion of new adopters that wouldn't immediately realize that the >>> s#s and the n#s have to be unique within the file. This might reduce a few >>> stubbed toes. >>> >>> Thoughts? >>> >>> -- >>> James Wennmacher - Unicon >>> 480.558.2420 >>> >>> >>> -- >>> 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 >>> >> >> -- >> >> 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 >> >> >> -- >> >> 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 >> >> > -- > > 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 > > -- > > 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 > > -- > > 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 > > -- 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
