Markup Interface Issues

[Rex Brooks <rexb@starbourne.com>]

Title: Markup Interface Issues

Hi Subbu, crew,

Here is the latest.

I added a paragraph on the two-step process in the Description, and used Subbu's rewrite, changing "dispatch" to send and "obtain" to receive.

I added a Markup Fragments and Aggregation subheading and paragraphs.

I added a CSS Portlet Classes subheading and pargraph.

I didn't add the remaining new headings from Subbu's last document per our last meeting.

I added two subheadings under renamed 5.2.Purposes Served:Two Step Protcol They are

5.2.1 Presentation: getMarkup() and

5.2.2 Interaction: performBlockingInteraction() I kept the existing text.

I/we need someone to step up and help out with several issues that Subbu brought up for URLs and Names, Managing Sessions and State Management, all of which I think belong in 5.5 Interaction Operations. Beyond what we already have on this topic, I don't know how much more is needed, except some discussion on cloning and URL rewriting. I haven't gotten to Users and Personalization yet. After the Description and all those details, do we really want to add an Overview/Summary?

I also did not add a Best Practices heading yet. This is definitely something someone who deals with developer teams on a regular basis should deal with.

Since I don't have a good reason to get involved with those issues at this point, even if I wrote it I would need someone to re-examine the needs, issues and options with me again. I have to confess that I am feeling a little stumped by some issues that I haven't revisited with developers in months now. Most of my own work projects are done and aren't turning up problems for me personally. I have the same problem with a couple of other issues

I haven't had time to really pay attention to the this since before Subbu's last attempt to reorganize the Markup Interface Section, and that situation is not getting better because I am getting busier. I thought summer would produce a slowdown. Silly me.

However, I am building a plan to address this, so please bear with me here.

When I came back to this I kept finding things that had changed with short notes for which I had no insights as to why such major structural changes were necessary. This is slowly resolving itself as I work through this material yet again. However, it is mostly reconfirming my opinion from our last meeting. If we were to change the structure of the Markup Interface, then I think we should reflect those changes in the other Interface sections, which I also think need some subheads to help people find specific topics. That explains why I had and have such problems with changing the overall approach to this section.

I didn't have the time before our last meeting to go over the document Subbu sent out with the proposed changes, luntil just before the last meeting. Then on the basis of the fact that it was such a departure from what we had done before, I thought we needed to stay with the previous structure which is shared at least in basic concept with the rest of the interface sections. That meant, I thought, I could simply plug in the new messages and it would work since my first glance at it showed that Subbu had indeed eliminated the one thing I objected to previously. That was the user authentication as an blocking Interaction example, which it really isn't. That step is preparatory to the first getMarkup() if user authentication is required.

However, that won't get our concepts better aligned, and it isn't what Subbu did, regardless.

I didn't notice that what Subbu had done was to start a new example which takes a step backward in the PInc/CInc process, at least with regard to the User. So, now I'm quite okay with that. I think I can work with that to the extent that it gets the basic two-step out of the way. It also takes care of performBlockingInteraction and portletStateChange and navigationalState. Hooray!

The one question I have is: do we think maybe that this first form should ask for a portlet symbol or a sumbol for the P Inc as the producer rather than a stock symbol since it appears that the user is asking for is the portfolio manager portlet which would then have the available stocks represented by their symbols inside the portlet? At least that's what it looks like to me, and actually works quite well in that way.

I had asked for what I thought was a different, but still pretty simple interaction: a request to add a new stock symbol to the ongoing Pinc/Cinc Portfolio Manager Portlet example. However, since Subbi asking for a variation and request/response examples, here's what the progression I propose.

getMarkup Request--this is just getting the User's regular Portfolio Manager. The User is already authenticated, has an account at both C Inc and P Inc and there should be the normal CIncRegnHandle with userContext as normal for whoever the User is. (Maybe not if we don't want to add all that stuff, let alone rework the previous messages, but then, do we want to explain that?)

getMarkup Response--regular Portfolio Manager portlet. (Can we add another interaction request to "view all available stocks" for this type of portfolio--like mutual funds v. variable annuities, offering a multiple choice? That would be getting rather complex, so not necessary.)

performBlockingInteraction Request--add new stock symbols, with, perhaps new stocks being added by producer to those available in this type of Portfolio Manager Portlet in a changePortletState example or in some other portlet on the same page.

performBlockingInteraction Response--done, including update?

Do we want to do all that?

I will attempt to pull together a Users and Personalization paragraph or three sometime in the next week.

Ciao,

Rex

-- 

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

WSRP Primer Markup Interface Rev 3.doc