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] <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 >> o 100 >> + 110 >> + 120 >> o 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 [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 [email protected] > <mailto:[email protected]> as:[email protected] > <mailto:[email protected]> > To unsubscribe, change settings or access archives, > seehttp://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, > seehttp://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
