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?
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.
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
I have no idea why the delimiter was changed. It may have been unintentional. Greg might know...
Looking at UserPreferenceNames, it looks like the only list prefs are:
- favorite resources - favorite groups - recent resources - recent groups (this one isn't used by portal-war, since it uses a single pref for recent resources and groups) - dashboard portlet columns (this one isn't used by coregui, since dashboards are now persisted in their own tables)
Recent-resources pref exceptions were reported when going to some of the Content tab iframes. However, the only thing I can think of that would use that pref on those pages would be the menu bar, which contains favorites and i think recents. If we make sure no iframe pages include the menu bar, we could eliminate these. Just yesterday I removed the menu bar from error.xhtml, which gets displayed if an uncaught exception occurs on any JSF page. Then there is the JSF dashboard, but since no iframe should display that, we could consider breakage there acceptable.
So we may be ok keeping the delimiters as is if we 1) make sure no JF pages that could get displayed in iframes include the menu bar, and 2) accept breakage on the JSF dashboard.
On 04/07/2011 09:06 AM, Jay Shaughnessy wrote:
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel@lists.fedorahosted.org