Using prototype to define classes accessible by both the server-side (ASP) & client-side

[iporter]

Although some javascript objects are client-specific (i.e. document)
and others server-specific (i.e. Response), much of prototype.js can
be used on the server-side.

In building a recent application, I found myself building converting
database data into HTML objects on the server-side, to ensure it
readable by the search engines, but having to largely duplicate that
code for the client-side to redraw the HTML when the user updated
things. I guess I could have used AJAX to get the server-side code to
return the HTML.

But I still need to have a client-side object, because I need to
unobtrusivly add client-side behaviours to the HTML. Thus, what I'd
like to be able to do, is define a class in a .js file, and then
inlcude that .js file with both the server-side and client-side code.

If you put the code, function test() {return 1;} in a .js file,
include this file in an ASP page using a <script runat="server"> tag,
and after this put <% Response.Write(test()) %>, you get '1' on the
page. However, if you add the code, var x = 2 to the .js file, and
put <% Response.Write(String(x)) %> in your ASP page, you get
'undefined'.

Interestingly, if you then remove the code x = 2 from the .js file,
but leave the call in the ASP page, you get a runtime error 800a1391
with a message saying, 'x is undefined'. Didn't our test before show
it was already undefined?

The point being, that if functions work, but variables don't, then I
can't use prototype's nice, var myClass = Class.create({}); syntax.

What gives? Can I get around this somehow? Or perhaps this is
ridiculous and you have a better approach to the problem?

Looking forward to your thoughts,
Iain

[Matt Foster]

I can't say I fully understand your troubles with ASP, maybe you
should boycott the evil empire and move on to greener pastures?

On the idea of having a web application that initiates with database
driven data on load and then has to interact with ajax requests to
update the document I suggest using a common service that serves XML.
Your asp environment will then be able to make the same call to
extract the XML and iterate over nodes for display as the ajax request
does. In this way you only have one "middle tier" that interacts with
your data. You have two displays though, one for Ajax, one for
traditional web, not the best case but when you've got to accommodate
a broad audience what can ya do.


Hope that helps,
Matt

[iporter]

Thanks Matt, I appreciate your thoughts.

On Jan 11, 2:22 pm, Matt Foster <mattfoste...@gmail.com> wrote:
> I can't say I fully understand your troubles with ASP, maybe you
> should boycott the evil empire and move on to greener pastures?

The more I learn, the more I'm tempted. But it would involve a bit of
a learning curve for which I don't currently have time.

> On the idea of having a web application that initiates with database
> driven data on load and then has to interact with ajax requests to
> update the document I suggest using a common service that serves XML.
> Your asp environment will then be able to make the same call to
> extract the XML and iterate over nodes for display as the ajax request
> does. In this way you only have one "middle tier" that interacts with
> your data. You have two displays though, one for Ajax, one for
> traditional web, not the best case but when you've got to accommodate
> a broad audience what can ya do.

Yup, I think this is what I'm referring to when I say, 'I guess I
could have used AJAX to get the server-side code to return the HTML.'
The problem I have with this is that I'd have to pass all the
parameters in addition to the data parameters. For example, if I
wanted to draw a menu with a server-side menu object, I'd have to pass
the database parameters plus menu object parameters like 'sortable',
'collapsible', etc. This doesn't seem intuitive.

[Gareth Evans]

As an aside, I develop in asp.net with prototype, and I can relate to what Iain is saying- you have to define your markup twice, however.. don't jump on the asp-bashing bandwagon just yet- you'd have to do the same in any server side language- cold fusion, php, asp; they all suffer from this.
Unless you develop your application to be completely client side driven, where the data is sent to the client and it is *transformed* to markup using templates, new Element et al; you end up having to place your markup in two places.

How do others get around this problem? it's a pain to decide, for example, a column needs to be in another position and having to change the markup in two places.
I can think of 3 solutions.

Solution 1
Store the 'template' data on the server side. Write a class to retreive it on the server side, and use (.net here) reflection to dynamically evaluate it, thus meaning the same markup structure #{key} can be used. On the client side, extend new Template so that the markup can be retreived from a URL.
Solution 2
Keep your markup entirely on the server, render the page as per normal except always render a hidden version of the markup with no data fields evaluated - then when the user changes data, grab the blank version and interpolate/evaluate your changes into it.
Solution 3
Store your markup in .js files and parse them on the server. do the same as 1.

Iain, I've not tried using js from a runat=server tag but I expect it's something to do with prototype being fairly advanced js and the microsoft interpreter being 'jscript'.
i would lean towards trying to find a different way to structure your application so that you don't need to include prototype on the server.
What variation are you using? vb.net / c#? .net 1 / 2? and what specific functions were you trying to leverage in prototype for use on the server?

I don't want to wind the PHP folk up here, but being able to leverage the .net framework and especially the Visual studio IDE speeds development up for me.
I know there are similar ide's available for other languages but I tend to feel that the php style of coding <? insert script here between your html ?> is way too similar to the classic asp <% insert script here %> model which never really worked in the first place.
PHP is definitely more advanced than classic asp, due to the large library of functions available, but I hasten to point out that the grass is *always* greener on the other side. Don't let the opinion of 'asp' cloud your judgement of asp.net as it's come a long long way.

Gareth

[Michael]

Have you guys ever used System.Web.Extensions.JsonSerializer. Its a
great way to serialize objects to json and back. I stopped shipping
markup and started shipping json as it drastically reduced my transfer
size. Why write rendering in .Net when prototype gives you real
objects to play with.

[Gareth Evans]

I use JsonNet myself. Same stuff but for .net 2, but even then..

sometimes you send a whole table down, then you need to dynamically add a row on the client side... there's various models available to implement this model of course...

 

 

On Jan 14, 2008 9:34 AM, Michael <89i...@gmail.com> wrote:

Have you guys ever used System.Web.Extensions.JsonSerializer.  Its a
great way to serialize objects to json and back.  I stopped shipping
markup and started shipping json as it drastically reduced my transfer
size.  Why write rendering in .Net when prototype gives you real
objects to play with.

> > > > Although some javascript objects are client-specific ( i.e. document)