tin-tags standards compliant

[Jeremy]

But in this case, what's wrong with using the final markup to begin
with? (In fact, for the example you gave, there are semantic XHTML tags
for that precise purpose - dl, dt, and dd - which would be styled
appropriately using CSS.)

Can you give me an example of the benefit of serving <tin...>...</tin>
and transforming it with javascript on the client side, rather than
either a) writing out the final markup to begin with, or b) using custom
markup on the server side, but transforming it before it gets to the
client?

P.S. - on a related note, if your markup doesn't validate (and <tin>
most certainly does not), then it's typically a pretty good clue that
you are on the wrong track as far as usability and compatibility are
concerned. There are valid reasons for having technically invalid
markup getting sent to the client, but I don't see this as one of them.

Jeremy

 

[Jeremy]

I have no problem with making things easier on the developer. You just
have to realize that the user is infinitely more important. The
application will only be developed once, but will be used by (hopefully)
incalculable multitudes, with no guarantee that your shortcuts will work
as intended. If you are trading off their experience for yours, when a
little extra typing will do the trick, you are making the wrong choice
IMHO.

One more thing, and I'll shut up. As an example for my self-quote, when
I look at the source your project's site, I am actually somewhat
appalled. You have absolutely no information in your document. This is
probably the worst way I can imagine to make a web site. I don't mean
to be a jerk, but I think most seasoned web developers would agree that
this is not the way to go.

Your site shows how the template system works - you have some XML markup
that gets loaded by Javascript and transformed into a corresponding HTML
document. Your site's example is somewhat similar to the concept of XUL
from Mozilla or Laszlo. But do you realize that this is a prime
use-case for server-side XSLT, which has been around for many years and
would serve easy-to-digest HTML to the client - rather than serving
essentially nothing and then making the client go out and fetch the
information before transforming it using 100% javascript? Even if you
don't want to do this server-side, every major browser at this point
supports client-side XSLT - meaning you can serve an XML document with a
<?xml-stylesheet?> directive pointing to your XSLT, and the client will
transform it for you.

I just want to make sure you know about the alternatives before you
become too invested in this idea. If you still feel like this is
something that is useful to you, then by all means pursue it. But I get
the feeling you are inventing a square wheel out of ignorance that a
round one exists.

Jeremy

 

[Thomas M. Farrelly]

Are you referring to something?

Yes. In javascript code in attributes one must exchange '<' for '&lt;' and
so on. So

Incorrect:
<tin init="if ( this.n > 0 ) alert( 'hi' ) ;" />

Correct:
<tin init="if ( this.n &gt; 0 ) alert( 'hi' ) ;" />

This at least is the case in FF. Others may allow anything other than
&quot;.

I do not consider this a major problem.

 

[Thomas 'PointedEars' Lahn]

Yes.

Then please quote the minimum of what you are referring to next time. TIA.

In javascript code in attributes one must exchange '<' for '&lt;' and
so on. So

Incorrect:
<tin init="if ( this.n > 0 ) alert( 'hi' ) ;" />

Correct:
<tin init="if ( this.n &gt; 0 ) alert( 'hi' ) ;" />

This at least is the case in FF. Others may allow anything other than
&quot;.

I do not consider this a major problem.

Well, it renders tin-tags use to be complicated. If tin-tags would support

<tin>
<init><![CDATA[
if (this.n < 0) alert('hi');
]]></init>
</tin>

as well, then it would stand a much greater chance of being used, theoretically.


PointedEars

 

[Thomas 'PointedEars' Lahn]

P.S. - on a related note, if your markup doesn't validate (and <tin>
most certainly does not), [...]

It's XML, not HTML.


PointedEars

 

[Thomas M. Farrelly]

]
In javascript code in attributes one must exchange '<' for '&lt;' and
so on. So

Incorrect:
<tin init="if ( this.n > 0 ) alert( 'hi' ) ;" />

Correct:
<tin init="if ( this.n &gt; 0 ) alert( 'hi' ) ;" />

This at least is the case in FF. Others may allow anything other than
&quot;.
[...]

Well, it renders tin-tags use to be complicated. If tin-tags would
support

<tin>
<init><![CDATA[
if (this.n < 0) alert('hi');
]]></init>
</tin>

as well, then it would stand a much greater chance of being
used,theoretically.

That is a good suggestion, and possible to do. I'll consider adding that.
It is particularly usefull for longer scripts. I suppose it also avoids
the problem with linefeeds beeing converted to spaces.

 

[Thomas M. Farrelly]

Sorry about late reply. Also haven't gotten around to fixing the IE
problems. Been working.

Tin-tags is not a template system. There is a module, template.xml, that
is written using tin-tags. It implements templates and concepts
assosiated with these. These templates are essentially the same as
templates in XSLT.

I see that there was ground for misunderstanding. I wanted to give an
example without the js code so that the connection between creating and
using tin-tags became clearer. I also think its very nice that the
template tin-tag is a meta-class

XSLT is a powerful tool. But it is not practical to use it to solve all
problems. Eventually you will fall back to javascript. Also, I think you
can only have one PI per XML document and this makes it impractical use in
situations where you need to have different views on the same data. You
have to invoke XSLT using javascript or add the correct PI server-side.

I consider creating a tin-tag that lets you load XML and transform it using
XSLT by writing:

<tin
instance="xslt"
source="path/to/source"
filter="path/to/filer"
/>

Or something like that. The filter attribute refers to the XSLT document.

In general, using many different tools to create a project results in
added complexity because you have to glue all these different tools
together and that requires programming and creates dependencies.

In the browser environment you know that you can always fall back on
javascript. Tin-tags allows for friendly integration of anything that can
be expressed using javascript, so when using it, you are guaranteed never
having to use traditional js hacking with global objects/functions and
id-attributes/tag-names and what not

Also, I think that inserting nonstandard tags into the document object is
perfectly fine even for browsers that do not understand namespaces. After
all, it's not HTML/XHTML anymore once it is parsed. It is a javascript
object with some event-based or similar connection to the graphical
representation of the document. Not sure I'm right about this though.

Thomas