[DG: User Experience] Refactor 3akai site membership role creation

[Ray Davis]

Since beginning to work with 3akai/K2, I've been frustrated by its
handling of site creation and memberships. First, apparently successful
builds often failed in practice. As a user, creating a site seemed to
take a long time. Then it turned out to be difficult to write clean
integration tests. And new annoyances show up as I try to plug in a new
UX component. I'll include a detailed analysis of the problems in a JIRA
ticket, but in brief I'd like to improve this area if it doesn't
conflict with Oszkar's or others' plans.

For now, I'd like to keep control of site role definitions in the hands
of UX-hosted client-side JavaScript. My goal would be to improve speed
(replace 13 HTTP POSTs with 2; eliminate redundant server-side logic by
more closely matching proven UX needs), stability (less chance of
interrupting the client-server chatter; ability to include "real" site
creation in unit and integration tests), predictability (rather than
relying on pattern-matching of Jackrabbit group IDs, which can easily be
wrecked by legitimate Sling activity, use clearly defined properties;
support full site deletion and the ability to re-create sites),
maintainability (centralizing the logic rather than having bits of it
replicated across files and layers), and flexibility (an easy central
location to modify roles; a clear path towards templatizing them).

Sound OK so far? Meeting these goals will involve coordinated changes,
so I expect I'd first try a solution on my UX and K2 branches, then (if
I'm successful) submit a backwardly-compatible K2 patch, and then (if it
gets merged) submit a UX patch to take advantage of the improved K2
functionality.

Thanks,
Ray
_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[jrnorman]

Is this different to the suggestion you made on October 26 on the  
Sakai Kernel list where Ian said please go ahead and contribute a patch?

John

On 6 Nov 2009, at 16:24, Ray Davis wrote:

> Since beginning to work with 3akai/K2, I've been frustrated by its
> handling of site creation and memberships. First, apparently  
> successful
> builds often failed in practice. As a user, creating a site seemed to
> take a long time. Then it turned out to be difficult to write clean
> integration tests. And new annoyances show up as I try to plug in a  
> new
> UX component. I'll include a detailed analysis of the problems in a  
> JIRA
> ticket, but in brief I'd like to improve this area if it doesn't
> conflict with Oszkar's or others' plans.
>
> For now, I'd like to keep control of site role definitions in the  
> hands
> of UX-hosted client-side JavaScript. My goal would be to improve speed
> (replace 13 HTTP POSTs with 2; eliminate redundant server-side logic  
> by
> more closely matching proven UX needs), stability (less chance of
> interrupting the client-server chatter; ability to include "real" site
> creation in unit and integration tests), predictability (rather than
> relying on pattern-matching of Jackrabbit group IDs, which can  
> easily be
> wrecked by legitimate Sling activity, use clearly defined properties;
> support full site deletion and the ability to re-create sites),
> maintainability (centralizing the logic rather than having bits of it
> replicated across files and layers), and flexibility (an easy central
> location to modify roles; a clear path towards templatizing them).
>
> Sound OK so far? Meeting these goals will involve coordinated changes,
> so I expect I'd first try a solution on my UX and K2 branches, then  
> (if
> I'm successful) submit a backwardly-compatible K2 patch, and then  
> (if it
> gets merged) submit a UX patch to take advantage of the improved K2
> functionality.
>
> Thanks,
> Ray
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>  with a subject of "unsubscribe"

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Ray Davis]

On 11/8/09 4:15 AM, John Norman wrote:
> Is this different to the suggestion you made on October 26 on the Sakai
> Kernel list where Ian said please go ahead and contribute a patch?

Yes, in two ways.

1. It's sent to the UX list rather than the K2 list.

2. It emphasizes changes in UX code rather than K2 code and mentions
that I'd like to keep configuration control in the hands of the UX
client-side JavaScript. (I hope to enlist advice from Eli and Oszkar
about proper packaging.)

Best,
Ray

>
> John
>
> On 6 Nov 2009, at 16:24, Ray Davis wrote:
>
>> Since beginning to work with 3akai/K2, I've been frustrated by its
>> handling of site creation and memberships. First, apparently successful
>> builds often failed in practice. As a user, creating a site seemed to
>> take a long time. Then it turned out to be difficult to write clean
>> integration tests. And new annoyances show up as I try to plug in a new
>> UX component. I'll include a detailed analysis of the problems in a JIRA
>> ticket, but in brief I'd like to improve this area if it doesn't
>> conflict with Oszkar's or others' plans.
>>
>> For now, I'd like to keep control of site role definitions in the hands
>> of UX-hosted client-side JavaScript. My goal would be to improve speed
>> (replace 13 HTTP POSTs with 2; eliminate redundant server-side logic by
>> more closely matching proven UX needs), stability (less chance of
>> interrupting the client-server chatter; ability to include "real" site
>> creation in unit and integration tests), predictability (rather than
>> relying on pattern-matching of Jackrabbit group IDs, which can easily be
>> wrecked by legitimate Sling activity, use clearly defined properties;
>> support full site deletion and the ability to re-create sites),
>> maintainability (centralizing the logic rather than having bits of it
>> replicated across files and layers), and flexibility (an easy central
>> location to modify roles; a clear path towards templatizing them).
>>
>> Sound OK so far? Meeting these goals will involve coordinated changes,
>> so I expect I'd first try a solution on my UX and K2 branches, then (if
>> I'm successful) submit a backwardly-compatible K2 patch, and then (if it
>> gets merged) submit a UX patch to take advantage of the improved K2
>> functionality.
>>
>> Thanks,
>> Ray
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-ux-unsubscribe@... with a subject of
>> "unsubscribe"
>
>

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[jrnorman]

OK, well I think I'd still say go ahead.

John

On 9 Nov 2009, at 14:14, Ray Davis wrote:

> On 11/8/09 4:15 AM, John Norman wrote:
>> Is this different to the suggestion you made on October 26 on the  
>> Sakai
>> Kernel list where Ian said please go ahead and contribute a patch?
>
> Yes, in two ways.
>
> 1. It's sent to the UX list rather than the K2 list.
>
> 2. It emphasizes changes in UX code rather than K2 code and mentions
> that I'd like to keep configuration control in the hands of the UX
> client-side JavaScript. (I hope to enlist advice from Eli and Oszkar
> about proper packaging.)
>
> Best,
> Ray
>
>>
>> John
>>
>> On 6 Nov 2009, at 16:24, Ray Davis wrote:
>>
>>> Since beginning to work with 3akai/K2, I've been frustrated by its
>>> handling of site creation and memberships. First, apparently  
>>> successful
>>> builds often failed in practice. As a user, creating a site seemed  
>>> to
>>> take a long time. Then it turned out to be difficult to write clean
>>> integration tests. And new annoyances show up as I try to plug in  
>>> a new
>>> UX component. I'll include a detailed analysis of the problems in  
>>> a JIRA
>>> ticket, but in brief I'd like to improve this area if it doesn't
>>> conflict with Oszkar's or others' plans.
>>>
>>> For now, I'd like to keep control of site role definitions in the  
>>> hands
>>> of UX-hosted client-side JavaScript. My goal would be to improve  
>>> speed
>>> (replace 13 HTTP POSTs with 2; eliminate redundant server-side  
>>> logic by
>>> more closely matching proven UX needs), stability (less chance of
>>> interrupting the client-server chatter; ability to include "real"  
>>> site
>>> creation in unit and integration tests), predictability (rather than
>>> relying on pattern-matching of Jackrabbit group IDs, which can  
>>> easily be
>>> wrecked by legitimate Sling activity, use clearly defined  
>>> properties;
>>> support full site deletion and the ability to re-create sites),
>>> maintainability (centralizing the logic rather than having bits of  
>>> it
>>> replicated across files and layers), and flexibility (an easy  
>>> central
>>> location to modify roles; a clear path towards templatizing them).
>>>
>>> Sound OK so far? Meeting these goals will involve coordinated  
>>> changes,
>>> so I expect I'd first try a solution on my UX and K2 branches,  
>>> then (if
>>> I'm successful) submit a backwardly-compatible K2 patch, and then  
>>> (if it
>>> gets merged) submit a UX patch to take advantage of the improved K2
>>> functionality.
>>>
>>> Thanks,
>>> Ray
>>> _______________________________________________
>>> sakai-ux mailing list
>>> sakai-ux@...
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-ux-unsubscribe@... with a subject of
>>> "unsubscribe"
>>
>>
>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>  with a subject of "unsubscribe"

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"