+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

Reply via email to