Re: [Templates] javascript implementation of tt?

> Still not quite sure what your objective is,

Simon Moore wrote:

>
> Still not quite sure what your objective is,

judging from your response, i'd have to disagree with you  ;)

> solution to a real world problem is: Flash MX Pro

ok.  duly noted, good points, but don't forget $$ here... not to 
mention, eep, the debate over open source vs. proprietary and 
additionally the requirement of a 3rd-party browser component

So, onto the point

> It can make asynchronous calls back to a server to receive images, 
> <!--flash movies-->, text, encoded value lists or XML (all of which TT 
> could generate).
>
> Essentially you can build a whole application in <!--flash--> [some 
> kind of DHTML type language] which gets downloaded to the browser once 
> and then requests back to the server when it needs new info [or to 
> post info] - minimising the load on the server (as only data is 
> exchanged once loaded - formatting that data is left to your 
> javascript running inside<!-- flash--> [the browser]).

This right here says it all - these are my goals, you nailed it.  And 
you go even further!

 >The advantages are smaller load on the server,
yeah, cool, whatever...

 >no flicker between pages loading,
killer.  i love it.  absolutely.  the work of the future.  this i must have.

But, as you state,

>
> The real downside to using this method is the time taken to build a 
> flash application is significantly longer than a normal html / 
> serverside TT or similar method.  Also interface changes take much 
> longer in flash although sometimes it can look better. 

...and you know what?  i don't need it to be pretty, and i don't want to 
pay the price (this price).  in fact, i want it to be, ahem, i mean, 
look as plain and simple as it can be.  i find myself building many 
heavily data-driven apps, and the interface to manipulate that data 
needs all the features you stated above (so you don't waste so much time 
page-loading, think GOMS) but actually would NOT prefer 
graphical/aesthetic value except to increase coherence of the data (as 
all that eye-candy will slow you down). 

I did remove this from the last quote:
 >There is generally a less good separation between the layers of an 
application - data,
 >presentation, navigation, with the last two inextricably muddled which 
is what really slows
 >development down.

and it is a good point and a danger to beware of with the approach I am 
seeking as well.

> you have a perfectly good DOM in all the major browsers

perfect?  it is good.. but perfect is a strong word, and i believe does 
not apply to the W3C D/HTML DOM.

> So if you really want a client side thing capable of doing clever 
> stuff using Javascript and want to avoid XML transforms,

nope, xml is A-OK, good even, _XSL_ however, is not.

"*XSL* is a family of recommendations for defining XML document 
transformation and presentation." -- w3.org/Style/XSL

and good at what it is designed for!  but a user interface is more 
complex than it's xml sub-structure.  xsl does not always make an 
optimal tool to express /in html and javascript/ the appearence and 
behavior desired of a GUI

> Hope that helps and wasn't too long winded :-)

it does, and it wasn't.  thanks!

-b

Simon Moore wrote:

>
> Still not quite sure what your objective is, but there is something 
> that might solve whatever your real world problem is: Flash MX Pro (No 
> doubt lots of people on the list don't like it any more than I do, but 
> it still has its place and its good points).
>
> It uses javascript (well it is based on ECMAscript which is what 
> javascript is based on - renamed to actionscript and now implements 
> the new class extensions which are great), which is an easy language 
> to use.
>
> It can make asynchronous calls back to a server to receive images, 
> flash movies, text, encoded value lists or XML (all of which TT could 
> generate).
>
> Essentially you can build a whole application in flash (particularly 
> using the new forms) which gets downloaded to the browser once and 
> then requests back to the server when it needs new info - minimising 
> the load on the server (as only data is exchanged once loaded - 
> formatting that data is left to your javascript running inside flash).
>
> The real downside to using this method is the time taken to build a 
> flash application is significantly longer than a normal html / 
> serverside TT or similar method.  Also interface changes take much 
> longer in flash although sometimes it can look better.  There is 
> generally a less good separation between the layers of an application 
> - data, presentation, navigation, with the last two inextricably 
> muddled which is what really slows development down.
>
> The advantages are smaller load on the server, no flicker between 
> pages loading, every time you update a value you don't immediately 
> have to return to the server with it and if you do it can be done 
> asynchronously and not interrupt the user experience.  This means you 
> can handle the user experience much better than web pages where there 
> is nothing you can really do during the web page load wait.
>
> Having said all that, I can say from experience I can reproduce almost 
> anything flash can do in html and javascript (DHTML) with a good 
> percentage of things  being easier (i.e. except really complex 
> animations and vector transforms).  So I agree with the people asking 
> why do you want TT in javascript when you have a perfectly good DOM in 
> all the major browsers?
>
> In practice I have developed systems using various server side 
> technologies (TT, ColdFusion, ASP) and used both DHTML and FLASH for 
> front ends.  Flash is particularly good for kiosk type apps, where you 
> want it to sit around for ages doing something pretty and only asking 
> the server for new data when such is required - i.e. where it is all 
> about user experience.  DHTML is better when time is an issue and you 
> want an application up and running and easy to update, fix and expand 
> upon when your requirements change.  Flash is very hard to work with 
> in an OO / modular way and consequently you don't get lots of reuse 
> (particularly graphical stuff, code is easier to reuse if you use 
> classes) - so when requirements change you often bin half a project.  
> OO can be done in flash, it is just so difficult to do well most 
> people don't do it fully. By comparison with web pages, you might lose 
> a whole web page but that has no affect on any other page (usually) as 
> they were all made separately in the first place and not 
> interdependent like Flash (which has no real concept of pages, the 
> nearest thing being the new forms).  Flash is also best a liner(ish) 
> things and not so good at things where you can jump around in any 
> sequence, forms overcome this to an extent
>
> So if you really want a client side thing capable of doing clever 
> stuff using Javascript and want to avoid XML transforms, DHTML and 
> Flash are two of the best ways of doing it, I don't think there is a 
> need for anything like TT.
>
> Hope that helps and wasn't too long winded :-)
> Simon
>
> At 09:17 31/03/2005, you wrote:
>
>> I'm looking for a tool that works pretty much exactly like template 
>> toolkit, but is implemented in javascript so the transform occurs on 
>> the client's machine.  it may work this way: a javascript hash (just 
>> like the perl hash) is given to the template object along with a 
>> string containing template code (or perhaps an id referring to the 
>> element containing the template code).  the template object then does 
>> the transform and returns that processed block (and puts it in 
>> another block... the same block whatever.... you get the idea)
>>
>> - i'm going out on a limb here, but, do you think it would be 
>> reasonable to implement the TT parsing engine in javascript?  since 
>> the answer is obviously no, it's unreasonable, does anybody know of 
>> anything akin to this?
>> (and i don't want to hear anything about xsl - xsl is a decent 
>> templating language for xml, NOT html and it doesn't work - i want a 
>> friendly syntax like this.)
>>
>> _______________________________________________
>> templates mailing list
>> templates@xxxxxxxxxxxxxxxx.xxx
>> http://lists.template-toolkit.org/mailman/listinfo/templates
>>
>>
>>
>> -- 
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005
>
>
>

_______________________________________________
templates mailing list
templates@xxxxxxxxxxxxxxxx.xxx
http://lists.template-toolkit.org/mailman/listinfo/templates