So as Eric pointed out, the two issues are actually separate. The id's serve two purposes. While persisting layout as a single entity would remove the need for so many database id's, it would not satisfy the needs of Dlm's diff strategy.
There may be an opportunity to separate these out in the short term, but ultimately Dlm needs to identify the individual bits of a layout in order to do it's job. Perhaps maintaining layout node identifiers would be simpler if the db we're not involved, but perhaps not! Certainly in the short term, the suggested spaceing approach would elevate some of the pain. Anyway, food for thought :-) Anthony. Sent from my HTC ----- Reply message ----- From: "James Wennmacher" <[email protected]> To: <[email protected]> Subject: [uportal-dev] Re: [uportal-dev] sequential IDs in layout-fragment.xml files contributing to commit noise Date: Sat, Jul 26, 2014 00:50 Hmm... great. Could you write up a proposal in a Jira so it can be discussed and maybe (someday) worked on? :-) James Wennmacher - Unicon 480.558.2420 On 07/25/2014 03:06 PM, Anthony Colebourne wrote: 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 - Unicon 480.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
