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]<mailto:[email protected]>> wrote: That's a good idea. Even simpler. Thanks! James Wennmacher - Unicon 480.558.2420<tel: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]<mailto:[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<tel:480.558.2420> -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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
