[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-primer] Markup interface
Actually, it isn't that I don't think navState belongs in Markup, but that it may not belong in the Primer altogether, since it is, in my opinion, more advanced than basic. Perhaps the developer's list, when OASIS provides it, would be a better place to answer questions about those issues. However, I'm not going to hold up work on that account. What I liked most out of your last refactoring, Subbu, and our discussion last week was the explanation for why we need to have markup fragments as portlets and not just rewrapped web pages. By extension, the necessity for making it possible to have different portlets from different producers on the same page as the lowest common denominator for the specification as a whole also makes some of the other issues that still need work a little easier to explain. That also provides a launching point for discussing CSS classes to ensure easy legibility and consistent look and feel. Since my abstract for XML 2004 was accepted, I will be stretched a bit thin getting ready for it, (I have to oversee a couple of groups of developers learning WSRP and CAP), but I think I can find time before next week to rework the Markup Interface using everything we have discussed and submit it for review by next Thursday. As of now that will include keeping navigationalState with the portletStateChange flag and the two-step process for getMarkup() and performBlockingInteraction() because the new markup messages do handle that now. I will do my best to provide the motivational basis for navigationalState as a way to cut down on repeating getMarkup() calls and for page refresh and bookmarking purposes. However, I really don't think it makes a lot of sense to get as deeply into "cloneBeforeWrite," "readWrite" and "readOnly" as the spec does. If someone wanted to come up with a good way to simplify a basic explanation for state management in Markup, the same way the markup fragments explanation works, that would be very helpful. There are only so many ways to say that we have to allow for different portlets from different producers on the same page and updating different portlets from the same producer during a performBlockingInteraction() provides a benefit we decided to allow. I would also be interested to hear other opinions. Ciao, Rex At 1:49 PM -0600 6/15/04, Subbu Allamaraju wrote: >Some comments from Rex during last week's call: > >a. It is good idea to set the motivation. >b. But it is inconsistent to emphasize the motivation with sub-headings >c. Should discussion on nav state belong the markup section? > >I'm posting these comments to the list to seek some comments/suggestions. > >Personally, I do think that we should set the motivation before >getting into details. I also agree with Rex that it may be >inconsistent to draw out subheadings for setting the motivation. >Given this, how about saying the same points without over >emphasizing with headings? I think we can still achieve the same >objective without. > >On the third point, based on the questions from portlet developers, >navigational state is an often confusing concept for non-portal web >developers. I personally think that the markup section motivate the >reason behind navigational state, and then show how can be used. The >messages I posted already illustrate navigational state. > >Regards, > >Subbu > >Rich Thompson wrote: > >> >>Based on questions I receive, it would be good to add a section >>describing usage of the CSS classes ... presuming someone will >>volunteer to author it of course. >> >>Rich >> >> >>*Subbu Allamaraju <subbu@bea.com>* >> >>06/10/2004 09:30 AM >> >> >>To >> wsrp-primer@lists.oasis-open.org >>cc >> >>Subject >> [wsrp-primer] Markup interface >> >> >> >> >> >> >> >> >>Based on the review comments we have had so far, I took a stab at >>refactoring(?) the markup section. The outline is attached (includes >>updated messages). I would like to hear your comments. Based on your >>comments, we can pull the content from the current draft and expand. >> >>Regards, >> >>Subbu -- Rex Brooks GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth W3Address: http://www.starbourne.com Email: rexb@starbourne.com Tel: 510-849-2309 Fax: By Request
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]