Mailing List Archive

EmbperlObject: parameters? (idea)
Hi,

one more question: any plan to parameters for components? Here's
exactly what I mean:


base.html
==================================
<html>
<head>
<title>[+ $param{title} +]</title>
</head>
<body bgcolor=[+ $param{bgcolor} +]>
<h1>[+ $param{title} +]</h1>
[- Execute ('*') -]
</body>
</html>


test.html
==================================
[- title => "Test1", bgcolor => "pink" -]
<p>This is test 1


There could be even way to specify defaults in base.html, maybe

[.- %default_params = ( title => "Test1", bgcolor => "pink" ) -]

I think the new version of Mason does it that way.

- Robert


P.S. When I read about first EmbperlObject, I jumped two meters, because
it's exactly what I need. Well, it doesn't work offline, but isn't very
urgent and I may find the courage to patch it myself eventually. But
parameters for components are quite necessary for all other my projects,
without them, I'd still have to start every file with

[- Execute ..., import => 1 -]
[- pagehead title => "Test1", bgcolor => "pink" -]
...
[- pagefoot copyright => "off" -]

etc, you've got the idea. Comments, anybody? Am I just missusing Embperl
big way?

P.S. Isn't it slowly becoming more like EmbperlTemplate? ;-)
Re: EmbperlObject: parameters? (idea) [ In reply to ]
>
> one more question: any plan to parameters for components? Here's
> exactly what I mean:
>
>
> base.html
> ==================================
> <html>
> <head>
> <title>[+ $param{title} +]</title>
> </head>
> <body bgcolor=[+ $param{bgcolor} +]>
> <h1>[+ $param{title} +]</h1>
> [- Execute ('*') -]
> </body>
> </html>
>

Rewrite it as

<title>[- Execute ('*#title') -]</title>

and put a

Execute (filename => '*', 'import' => 0') ;

at the top of base.html (this line is only neccessary for now, it will be
automaticly executed in the next release)

your test.html defines

[$sub title $] My Title goes here [$endsub$]

>
> P.S. When I read about first EmbperlObject, I jumped two meters, because
> it's exactly what I need. Well, it doesn't work offline, but isn't very
> urgent and I may find the courage to patch it myself eventually. But
> parameters for components are quite necessary for all other my projects,
> without them, I'd still have to start every file with
>

I think calling subs like a I describe above should serve the same purpose,
doesn't they? I surely will extent EmbperlObject in the future, to have more
and better possibilities.

Gerald

>
> P.S. Isn't it slowly becoming more like EmbperlTemplate? ;-)
>

Embperl 2 will become much more ;-)
Re: EmbperlObject: parameters? (idea) [ In reply to ]
Aha. So you recommend every EmbperlObject file from my example looks
like

==================================
[$ sub title $]Test 1[$ endsub $]
[$ sub bgcolor $]#ff0000[$ endsub $]
[$ sub copyright $]1[$ endsub $]
<p>Test page</p>

I guess it's usable but I'd like better something like

==================================
[.- setparams title => "Test", bgcolor => "#ff0000", copyright => 1 -]
<p>Test page</p>

Anyway, several [$sub$]'s in every file, what about performance (vs.
some kind of sending around param list/hash)? Moreover, how would you
set up defaults? Can I have

[$ sub bgcolor $]some default background color[$ endsub $]

in the base.html and then redefine it in the EmbperlObject files as/when
needed?

- Robert


Gerald Richter wrote:
>
> >
> > one more question: any plan to parameters for components? Here's
> > exactly what I mean:
> >
> >
> > base.html
> > ==================================
> > <html>
> > <head>
> > <title>[+ $param{title} +]</title>
> > </head>
> > <body bgcolor=[+ $param{bgcolor} +]>
> > <h1>[+ $param{title} +]</h1>
> > [- Execute ('*') -]
> > </body>
> > </html>
> >
>
> Rewrite it as
>
> <title>[- Execute ('*#title') -]</title>
>
> and put a
>
> Execute (filename => '*', 'import' => 0') ;
>
> at the top of base.html (this line is only neccessary for now, it will be
> automaticly executed in the next release)
>
> your test.html defines
>
> [$sub title $] My Title goes here [$endsub$]
>
> >
> > P.S. When I read about first EmbperlObject, I jumped two meters, because
> > it's exactly what I need. Well, it doesn't work offline, but isn't very
> > urgent and I may find the courage to patch it myself eventually. But
> > parameters for components are quite necessary for all other my projects,
> > without them, I'd still have to start every file with
> >
>
> I think calling subs like a I describe above should serve the same purpose,
> doesn't they? I surely will extent EmbperlObject in the future, to have more
> and better possibilities.
>
> Gerald
>
> >
> > P.S. Isn't it slowly becoming more like EmbperlTemplate? ;-)
> >
>
> Embperl 2 will become much more ;-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
Re: EmbperlObject: parameters? (idea) [ In reply to ]
> Aha. So you recommend every EmbperlObject file from my example looks
> like
>...

yes

> Anyway, several [$sub$]'s in every file, what about performance (vs.
> some kind of sending around param list/hash)?

Shouldn't be a great problem

> Moreover, how would you
> set up defaults?

Currently you can't.


But you can make the sub return a value (or better a hashref of all your
values) via

[$ sub params $]
[- $_[0] = { title => 'test', bgcolor => 1 } -]
[$endsub$]


Then you call it like

[.- Execute ({inputfile => '*', sub => 'params', param => \@params}) ; -]

and now you have your hash ref in $params[0].

Ok, this isn't the greatest solution, but it works and should deliver what
you need. I know that there is still work to do in this direction and ideas,
like yours, are welcome.

Gerald
Re: EmbperlObject: parameters? (idea) [ In reply to ]
> <title>[- Execute ('*#title') -]</title>

I have a similar setup and a problem with that.

I want to add some javascript to the next page, so I have this:

Execute ({inputfile => '*', 'sub' => 'js_start', output => \$js_start})
<BODY [+ $js_start +] >

(abbreviated, the syntax may not work, but you get the idea.

The problem is that I don't know the javascript until late in my original page,
so how can I let the js_start sub wait until I know what to put in it?

Maybe the answer is straight forward, but I'm too tired to see it now.

--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2582
Howitzvej 75 Åben 14.00-18.00 Email: kar@webline.dk
2000 Frederiksberg Lørdag 11.00-17.00 Web: www.suse.dk
RE: EmbperlObject: parameters? (idea) [ In reply to ]
>
> I want to add some javascript to the next page, so I have this:
>
> Execute ({inputfile => '*', 'sub' => 'js_start', output => \$js_start})
> <BODY [+ $js_start +] >
>
> (abbreviated, the syntax may not work, but you get the idea.
>
> The problem is that I don't know the javascript until late in my
> original page,
> so how can I let the js_start sub wait until I know what to put in it?
>

So you want to have the Execute of the sub to be below the BODY tag where
you include the result of the Execute?

This isn't possible :-( Or did I get the question wrong?

Gerald

-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
RE: EmbperlObject: parameters? (idea) [ In reply to ]
>
> The problem is in the original file. I have (from memory, I'm not at that
> computer now)
>
> [$sub js_start $] [+ udat{onload} +] [$endsub$]
>
> in the top of the file. Later I decide what to put into udat{onload}, but
> then it's too late because the sub js_start has already been fired.
>

So you can either call the file and save the result in a variable (like you
do it with js_start) and include it later in your page, or you must move
your decision (what goes into udat{onload}) to the sub and save the result
to use it laster in your form.

Gerald

-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: EmbperlObject: parameters? (idea) [ In reply to ]
Gerald Richter wrote:
> ...
>
> Rewrite it as
>
> <title>[- Execute ('*#title') -]</title>
>
> and put a
>
> Execute (filename => '*', 'import' => 0') ;
>
> at the top of base.html (this line is only neccessary for now, it will be
> automaticly executed in the next release)
>
> your test.html defines
>
> [$sub title $] My Title goes here [$endsub$]
>
> ...

Hi,

I'm playing with your solution and while it seems to work, but I've
found three more problems:

- I need to post-process result of the Execute so I try

<title>[- Execute({ inputfile => '*#title', output => \$x }) -] [+
process($x) +]</title>

but EmbperlObject complains file '*#title' doesn't exists. Fortunately
following works

<title>[.- Execute({ inputfile => '*', sub => 'title', output => \$x })
-]
[+ process($x) +]</title>

- I'm having problems with caching Execute results: even when I turn it
off with mdate => undef

<title>[.- Execute({ inputfile => '*', sub => 'title', output => \$x,
mtime => undef }) -]
[+ process($x) +]</title>

it still shows old values. The problem matifests itself in several
browsers but reload would always fix it: I guess it must be
EmbperlObject problem. (I'll make simplified case if it's necessary).

- Irregularly but quite often EmbperlObject fails with 'function not
defined' even if the function is normal perl sub defined in the
base.html - reload always fixes it.

And finally I guess it might be a good idea to (make possible to) export
base.html subs so they're available in the pages.

- Robert
Re: EmbperlObject: parameters? (idea) [ In reply to ]
Hi,
>
> I'm playing with your solution and while it seems to work, but I've
> found three more problems:
>
> - I need to post-process result of the Execute so I try
>
> <title>[- Execute({ inputfile => '*#title', output => \$x }) -] [+
> process($x) +]</title>
>
> but EmbperlObject complains file '*#title' doesn't exists. Fortunately
> following works
>
> <title>[.- Execute({ inputfile => '*', sub => 'title', output => \$x })
> -]
> [+ process($x) +]</title>
>

Yes, the *#title syntax only works in the short form. i.e. Execute
('*#title') ;

> - I'm having problems with caching Execute results: even when I turn it
> off with mdate => undef
>
> <title>[.- Execute({ inputfile => '*', sub => 'title', output => \$x,
> mtime => undef }) -]
> [+ process($x) +]</title>
>
> it still shows old values. The problem matifests itself in several
> browsers but reload would always fix it: I guess it must be
> EmbperlObject problem. (I'll make simplified case if it's necessary).
>

This has nothing to do with the mtime paramter. mtime only is responsible
for the caching of the compiled perl code, but _not_ for the result. The
page is always executed and should compute a new result. Looks like there
must be another reason. Maybe a problem with closures?

> - Irregularly but quite often EmbperlObject fails with 'function not
> defined' even if the function is normal perl sub defined in the
> base.html - reload always fixes it.
>

How do you call the functions? Where are the functions definied? In the same
file?

> And finally I guess it might be a good idea to (make possible to) export
> base.html subs so they're available in the pages.
>

I plan to add more features at the end of the month (or starting of july).
Then I will add some scheme of inherance/import/export, not quite sure
what's the best yet.

Gerald
Re: EmbperlObject: parameters? (idea) [ In reply to ]
Gerald Richter wrote:
>
> > - I'm having problems with caching Execute results: even when I turn it
> > off with mdate => undef
> >
> > <title>[.- Execute({ inputfile => '*', sub => 'title', output => \$x,
> > mtime => undef }) -]
> > [+ process($x) +]</title>
> >
> > it still shows old values. The problem matifests itself in several
> > browsers but reload would always fix it: I guess it must be
> > EmbperlObject problem. (I'll make simplified case if it's necessary).
> >
>
> This has nothing to do with the mtime paramter. mtime only is responsible
> for the caching of the compiled perl code, but _not_ for the result. The
> page is always executed and should compute a new result. Looks like there
> must be another reason. Maybe a problem with closures?
>
> > - Irregularly but quite often EmbperlObject fails with 'function not
> > defined' even if the function is normal perl sub defined in the
> > base.html - reload always fixes it.
> >
>
> How do you call the functions? Where are the functions definied? In the same
> file?

No closures, some functions are defined in the same file, some are
imported. It happens on my devel server only, I have just concluded I
can't reproduce it on my production server. There is only one real
difference between those: DocRoot on my devel server is windows disk
mounted through Samba. Samba does have small some problems on my devel
server (sometimes it doesn't see things have changed on the mounted disk
etc) so I tend to think both problems are somehow samba-related. I don't
really need Samba (too lazy I guess) so I am not going to investigate it
further unless it happens on production server or somebody is terribly
interested.

> > And finally I guess it might be a good idea to (make possible to) export
> > base.html subs so they're available in the pages.
> >
>
> I plan to add more features at the end of the month (or starting of july).
> Then I will add some scheme of inherance/import/export, not quite sure
> what's the best yet.

These pages I'm talking about go online tommorow, I'm changing back to
plain Embperl right now. I'm going to work on them some more in a month
or two and I guess I'll try to put it back into the EmbperlObject, esp.
if some cool new stuff comes out. Most my problems with EmbperlObject
come from parameters passing around and subs importing/exporting, it can
mostly be worked around, but it looses the elegance of the EmbperlObject
idea.

- Robert
RE: EmbperlObject: parameters? (idea) [ In reply to ]
> Most my problems with EmbperlObject
> come from parameters passing around and subs importing/exporting, it can
> mostly be worked around, but it looses the elegance of the EmbperlObject
> idea.
>
Next release will bring you the elegance back (hopefully).

Gerald