Passing Arguments for Components

[jcobb]

Not strictly share development - I'm working on a surf application. I'm pretty new to the idea of components / dashlets / widgets etc.

Let's say I have a component that's a clock, and it can display time either digital or analogue. I can use post or get arguments to change the display. I also have another component, for example a login panel that posts username and password to a webscript to log the user in.

My question is this  - is there a best practice way of passing arguments (eg which type of clock to display) across page reloads, so that components can persist their state and remain independent of what's happening with other components?

I created a register component for surf - my first attempt had the webscript that processes the form data redirecting back to the calling page with success or error codes in the url (eg ?registerError=No username). Realising that either other components won't then persist their state if they rely on the url, or the url will get permanently over crowded, I tried storing these codes and messages as properties of the component I was redirecting back to. Which worked fine,and I was mighty proud of my work until I realised of course this isn't session specific, so will stop working when the second user logs on!

So - with all those 'portlets' out there, there must be some recognised ways of persisting component session data without using the url or POST data. How best do we do this in surf?

I've looked at the share source code briefly hoping for an answer, but in share the post urls for forms etc are all obscured by the yahoo gui, which I'm not familiar with.

Any thoughts appreciated. I've got the bones of my surf application - home page, login component, register component, but before I go much further I'd like to make sure I have a sensible architecture in place.

James Cobb

[jcobb]

OK so to update my post:

One tip from Share is to minimise page reloads from the server - which means using javascript on the client to interact with the user. In particular use of the yahoo gui. So for instance when browsing the document tree in share, the url might be

http://server:8080/share/page/site/siteName/documentlibrary#path=%252FdocumentFolder&page=1

That way javascript on the client can 'reload' the component, without a page reload.

Another tip from browsing share sources is to use the Preference Service - see wiki pages. This can be used to hold user preferences both within and across sessions - for example whether the document library opens in simple view or not. This would be the solution to my example of a clock widget having different display options.

I've also discovered some references to session data - eg

request.getSession().setAttribute(SESSION_CURRENT_THEME_ID, themeId);

in the AbstractRequestContext -to set a theme.

Is that something one can use in a surf application to pass session variables without using the url, where one doesn't need the cross-session persistence of using the preference service?

James