On May 8, 2010, at 5:09 AM, Schmitz, Jeffrey A wrote:

> OK, some pretty cool stuff, but I'm having a little trouble getting my head 
> wrapped around how exactly to implement it in a "real world" webapp.  First a 
> couple specific ?s and then a couple of broad questions:
> 
> 1. In the spin.ui:ArgumentsList definition I noticed it is a subclass of 
> html:Div.  The writeup doesn't mention this so I was wondering what the 
> significance of this is, i.e. what does it buy you?  I'm guessing that class 
> needs to match the outermost html element in the prototype, but what if it 
> doesn't?  I'd rather not have to "hard code" it's element type as its 
> superclass unless it's buying something.  Does it just help guide the 
> renderer or is there more significance?

The only effect of sub-classing is that you inherit the argument declarations, 
and this is significant if you want to reuse existing variables, or if you want 
to enable the users of your component to set the same arguments. For example, 
it might make sense to subclass html:Div so that people can set HTML attributes 
such as style and class. In many real-world cases (and I am basically 
discovering those patterns on the fly, and more experience may invalidate those 
observations) is that I just subclass ui:Element directly (or with something to 
group them logically in between).

> 
> 2. Again concerning spin.ui:ArgumentList, would it be a good idea to make 
> rdfs:Class the spl:valueType of the spin.ui:module Argument (instead of 
> spin:Modules)? That way the ArgumentList prototype could be used for any 
> class with Arguments defined for it, and not just spin:Modules.

The valueType is not enforcing constraints right now, and you can pass in 
anything you like. But yes, in principle other classes can have arguments as 
well and I should change this.

> 
> 3. In a broader sense, how would one go about building a web-app by using and 
> reusing these snippets of html?  Again no need to explain details, but just 
> wondering (in a very general sense) what the controller layer is in the TBS 
> ecosystem?  And where are the decisions made about page navigation and which 
> renderings of class data to use on each page?

I have extended this recently, for 3.3.2 onwards. This includes a generic 
mechanism of redirecting HTML links, and a ui:link function. It will become 
clearer then. But in general, I have some demos in which UISPIN pages have HTML 
forms that call SPARQLMotion scripts, which in turn create new UISPIN pages 
(with the new module sml:ReturnUISPINDocument). This way, the app work flow is 
similar to languagues like JSP or PHP. I am not sure yet how to support 
"global" pages that have no meaningful attachment to classes, and no need for 
?this etc. I will need to collect more experience and appreciate input from the 
community.

> 
> 4. Also, I'm still unsure of how to define and choose from multiple 
> renderings of the same class, other than possibly building a different ui 
> model for each different rendering.  It's almost leading me to an 
> architecture where each page in a web app would have a different ui model 
> defined for it that perhaps re-uses some renderings defined in a "common" ui 
> model and also defines some of its own custom, page specific renderings.  But 
> I have just a little experience with SPARQLMotion, and none with TBL, so I'm 
> probably missing something.

See my previous email, with ui:id. Otherwise, I would try to make the structure 
as object-oriented as possible, so that the model inform the rendering.

> 
> Finally, any plans to make the uispin rendering engine a part of the SPIN 
> open source API? :-)

Possibly later, yes. Meanwhile, it will be part of the TBL product from 3.3.2 
onwards.

Regards
Holger

-- 
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en

Reply via email to