forwards and backwards compatible user preferences

Jay Shaughnessy jshaughn at redhat.com
Thu Apr 7 13:06:25 UTC 2011


I don't suppose we know why it was change?  Any sort of javaScript 
reason perhaps?   What exactly will fail in the JSF is we leave it as 
is?  painful to make changes to support JSF...

On 4/5/2011 4:24 PM, Ian Springer wrote:
> Looking more closely, it looks like the delimiter for list prefs was
> changed from "," to "|", whereas in portal-war, "|" was used to delimit
> parts within a list item ...
>
> Specifically, coregui UserPreferences has:
>
>      protected static final String PREF_LIST_DELIM = "|";
>
> while portal-war SubjectPreferencesBase has:
>
>      protected static final String PREF_LIST_DELIM = ",";
>      protected static final String PREF_ITEM_DELIM = "|";
>
> I think we should change coregui to use the same delimiters as
> portal-war - otherwise all list prefs will be incompatible between wars.
>
> On 04/05/2011 04:11 PM, John Mazzitelli wrote:
>> I don't think we need to put too much work into the JSF side. But we
>> have to be careful with the JSF pages will STILL use (for the gwt
>> iframes). Those, obviously, have to still work.
>>
>> On 04/05/2011 04:09 PM, Ian Springer wrote:
>>> On 04/05/2011 04:03 PM, John Mazzitelli wrote:
>>>> yeah. I hit the same problem with the user preferences for the metric
>>>> display range. I ended up having to play games with it to get both the
>>>> jsf and gwt code to play nice together - I had to make sure the values
>>>> they store in preferences are understood by both sides. And if the
>>>> values are legacy, we have to keep in mind people in the field have old
>>>> values that we need to support (either accept the old values or do a
>>>> conversion if we see the old value syntax and set it to the new syntax -
>>>> and make sure the jsf code does the same).
>>>>
>>>> there is nothing wrong by changing the jsf code to work with the new
>>>> syntax - just make sure we can convert any old values sitting in a
>>>> customers DB from an old version to the new syntax. We can't blow up to
>>>> support upgrades.
>>> The thing I don't like about this is its extra work on the JSF side to
>>> make it handle both formats - work that will eventually be thrown away
>>> once we jettison portal-war.
>>>
>>> And in the recent resources example, I suspect supporting the both
>>> formats in both wars isn't even feasible, since portal-war's format
>>> supports both resources and groups, and the two formats don't even use
>>> the same delimiters.
>>>> On 04/05/2011 03:59 PM, Ian Springer wrote:
>>>>> I am looking at https://bugzilla.redhat.com/show_bug.cgi?id=693411. It
>>>>> appears the root cause of the issue is that the format of the
>>>>> ".recent.resources" preference's value was changed in coregui from the
>>>>> format used by portal-war. coregui uses:
>>>>>
>>>>> resourceId|resourceId|resourceId,...
>>>>>
>>>>> but portal-war uses:
>>>>>
>>>>> entityId|entityType|name,entityId|entityType|name,...
>>>>>
>>>>> where entityId is either a resource or group id, and entity type is
>>>>> either "resource" or "group".
>>>>>
>>>>> I think we should try to keep the format of existing preferences the
>>>>> same, and if we absolutely do need to change the format of a preference,
>>>>> we should change its name too. That way when a user upgrades from RHQ
>>>>> 3.x or JON 2.x, their existing preferences will still work, both on the
>>>>> coregui side and on the portal-war side (for iframes).
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> _______________________________________________
>>>>> rhq-devel mailing list
>>>>> rhq-devel at lists.fedorahosted.org
>>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>> _______________________________________________
>>>> rhq-devel mailing list
>>>> rhq-devel at lists.fedorahosted.org
>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>


More information about the rhq-devel mailing list