You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Scott Chapman <sc...@mischko.com> on 2001/11/09 00:02:52 UTC

Modular web site not behaving as expected.

I am trying to build a web site out of standalone pages that are 
called from a top level page.

When I call a sub-page, they return immediately.  How do I prevent 
this.

For instance, I have a main page that looks like this:

[-  do some processing

    execute sub page sending fdat in as parameter so I can get 
results back.

    do some processing

    execute sub page sending fdat in again.
    .
    .
    .

-]

Each sub page is a standalone unit, typically a form with data 
checking, where the form calls the same page to do the checking 
(similar to neu.htm example shipped with EmbPerl).

After the data checking is completed, THEN it should return to the 
calling page, not before.

How do I set this up?  I want to make very modular web sites this 
way.

Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web sites - is this possible? (was Re: Modular web site not behaving as expected.)

Posted by Andrew O'Brien <an...@switchonline.com.au>.
On Thu, Nov 15, 2001 at 03:05:24PM -0800, Scott Chapman wrote:

To summarise your summary:

You want Embperl to implement an Execution state machine for you.

I've just implemented a largish, completely forms based site using
just that code snippet I posted earlier for progression. There were a
few extra things for moving backwards and jumping around the execution
tree but thats was basically it.

I agree completely with you that it would be nice to be able to
conceptually program like you wish .... but with a small wrapper in
place you can do it yourself and not have to wait for Gerald to muck
around in Embperl internals to get the same thing :)

> I posted a very similar question on the ModPerl list and someone 
> else summarized my request very nicely. This may help:  
> 
> > On 15 Nov 2001, at 15:33, Perrin Harkins wrote:
> > 
> > The original e-mail was confusing, but I think what he's after is not
> > so much the ability to call pages as subs but rather the ability to
> > abstract away the fact that a sub might actually involve multiple user
> > interactions (present a form, get a response, present another form,
> > etc.) with breaks in actual execution.  In other words, he wants to
> > think of program execution in terms of a linear user session (as you
> > would with a GUI app) rather than a series of separate requests. 

-- 
 Andrew O'Brien                                                               
 Product Engineer                        email: andrewo@switchonline.com.au.
 Switch Online Group Pty Limited         phone: +61 2 9299 1133             
 ABN 89 092 286 327                      fax: +61 2 9299 1134             

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web sites - is this possible? (was Re: Modular web site not behaving as expected.)

Posted by Gerald Richter <ri...@ecos.de>.
I think I got now what you want...

>
> Do you still think this is possible?
>

It's possible, but not easy to do in a common and abstract way on the other
side it's not hard to do it for a concret problem, like Andrew said.

I will think about this and maybe come up with an idea, but at the moment I
can't say how a concrete implementaion could look like, so it's more a long
term perspective...

> > Gerald wrote:
> > Yes, this is possible and especially for form validation I have some
plans
> > in mind, which I can hopefully release before the end of the year, which
> > will allows you to specify validation rules and what should happen if
the
> > validation fails.
>
> Typically, I just have a form call itself for validation with appropriate
> conditionals.  What do you have in mind here?
>

1.) Give you an extentable library of "conditionals", so you don't have to
code them every time
2.) Let Embperl verify these conditional for you and take an action (e.g.
call different pages), depending on the result

So basicly it does the same as you also do, just do it for you, so you don't
have to do everytime the same.

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 925131
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web sites - is this possible? (was Re: Modular web site not behaving as expected.)

Posted by Scott Chapman <sc...@mischko.com>.
On 15 Nov 2001, at 21:26, Gerald Richter wrote:

> There are many nice ideas (and I have a lot of them too), but it takes also
> a lot of time to implementing them and as long as nobody pays me for that
> (which is fortunately sometimes the case :-), I have to do things that I
> need for my projects first and keep the other nice features for the time
> that is left. I says this here, because I could imagine that implementing
> something like you have in mind, would be really cool, but also would be a
> lot of work. Haveing this said, I really like to hear your ideas and discuss
> them and as far as we come up with good solutions try to integrate them into
> Embperl!

I appreciate the busy problem and all the great stuff you've done 
with Embperl!  I think it is part of the human condition to be too 
busy to get it all done in one lifetime.  Let me know how difficult it 
looks after you read the rest of this.  

[- snipped -]

I posted a very similar question on the ModPerl list and someone 
else summarized my request very nicely. This may help:  

> On 15 Nov 2001, at 15:33, Perrin Harkins wrote:
> 
> The original e-mail was confusing, but I think what he's after is not
> so much the ability to call pages as subs but rather the ability to
> abstract away the fact that a sub might actually involve multiple user
> interactions (present a form, get a response, present another form,
> etc.) with breaks in actual execution.  In other words, he wants to
> think of program execution in terms of a linear user session (as you
> would with a GUI app) rather than a series of separate requests. 

He summarized it just right.  I'd like to have an abstraction that 
effectively removes the stateless nature of this.  HTML was not 
made as a 2-way thing so using it is painful some times.  Can it be 
made more like a typical programming scenario?

A typical example:
1) Top level page calls another page to present a form. Execution of the calling page is stopped (actually suspended) waiting for the return to happen.
2) The form is presented to the user and processing stops while waiting for the reply.
3) The user submits the page either to the calling page or to another one (doesn't matter). Validation happens.
4) Other pages could be called either as modules (like step 1) or like they are called now.
5) Final page executes a "return" statement and processing returns to the top level calling page and continues where it left off.

In order to implement this:

The calling page needs to be able to continue execution when the call is returned.

Pages that are called need to know that they are not to drop out 
the bottom and return to the calling page but to stop instead.  

The called page needs to pass on the return-to information or a 
"stack" needs to be implemented for the session so that the 
eventual return causes execution to go back to the top-level calling 
page like you would expect.  

> Is your idea, chaining these pages together, so that one page would only be
> displayed if the previous one is done ?  Or is a module as see it only a
> part of a page, so you can have lets say a user add form and a mail form or
> what ever on the same page ?

The idea is that a group of pages become a module, with a single 
entry point and a single return point. Flow of control among the 
pages in a module would be done normally (as done right now), 
including the possibility of calling other modules.  

> Is your idea mainly for input forms or do you have other sort of 
> objects in mind ? If yes, what ?

Not form specific at all.  Just a generic control structure that 
makes a group of stateless transactions behave like a regular 
subroutine in a modular language.  Generic is more useful.  

> > Scott wrote:
> > I realize this is a stateless arena and implementing this would
> > require some magic but think Embperl (and you) are able to
> > make that kind of magic.  Is this possible or does the stateless 
> > nature of this make it impossible?  More modularity would be
> > SO nice in this environment!

Do you still think this is possible?

> Gerald wrote:
> Yes, this is possible and especially for form validation I have some plans
> in mind, which I can hopefully release before the end of the year, which
> will allows you to specify validation rules and what should happen if the
> validation fails.

Typically, I just have a form call itself for validation with appropriate 
conditionals.  What do you have in mind here?   

Cordially,
Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web sites - is this possible? (was Re: Modular web site not behaving as expected.)

Posted by Gerald Richter <ri...@ecos.de>.
Hi,

>
> I've been giving a lot of thought to the idea of modular web pages
> and "exit" functionality is not nearly as nice as what I think you
> could build into embperl.
>

There are many nice ideas (and I have a lot of them too), but it takes also
a lot of time to implementing them and as long as nobody pays me for that
(which is fortunately sometimes the case :-), I have to do things that I
need for my projects first and keep the other nice features for the time
that is left. I says this here, because I could imagine that implementing
something like you have in mind, would be really cool, but also would be a
lot of work. Haveing this said, I really like to hear your ideas and discuss
them and as far as we come up with good solutions try to integrate them into
Embperl!

> ....
> It would be very nice to have Execute handle this with a parameter
> saying "Don't return here until you're told to by the page I'm
> calling".  PageB executes and at the end of PageB it automatically
> stops (like "exit" would do) but it keeps track of where it's
> supposed to return to internally like a regular subroutine would in a
> modular programming language.  When PageB finally executes a
> "return to calling page" command (perhaps passing parameters
> back like perls "return" statement), then and only then would
> PageB actually drop out the bottom and return to PageA.
>

Is your idea, chaining these pages together, so that one page would only be
displayed if the previous one is done ?  Or is a module as see it only a
part of a page, so you can have lets say a user add form and a mail form or
what ever on the same page ?

Is your idea mainly for input forms or do you have other sort of objects in
mind ? If yes, what ?

> I realize this is a stateless arena and implementing this would
> require some magic but think Embperl (and you) are able to make
> that kind of magic.  Is this possible or does the stateless nature of
> this make it impossible?  More modularity would be SO nice in this
> environment!
>

Yes, this is possible and especially for form validation I have some plans
in mind, which I can hopefully release before the end of the year, which
will allows you to specify validation rules and what should happen if the
validation fails.

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 925131
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------




---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web sites - is this possible? (was Re: Modular web site not behaving as expected.)

Posted by Scott Chapman <sc...@mischko.com>.
Wim,

It may be possible with more complex coding but the idea is 
transparent abstraction layer here to make things behave just like 
calling a regular subroutine with a return statement at the end.  I'm 
hoping to hear from Gerald on the possibility of implementing this 
into Embperl.  It would be a serious improvment in the way we can 
make web sites where we don't have to spend as much time 
thinking about the problem and more time thinking in terms of the 
solution.  That's the promise of object oriented programming! :-)

Cordially,
Scott

On 15 Nov 2001, at 10:44, Wim Kerkhoff wrote:

> Hi Scott,
> 
> I think I understand your point better now. I'm still convinced that it
> is possible to do what you have described using EmbperlObject. 
> 
> Wim
> 
> Scott Chapman wrote:
> > 
> > Wim,
> > I think you missed the point of our discussion. This isn't about
> > authentication at all. It's about modular site design.  The web page
> > I was talking about is just for getting a userid, password and email
> > address to CREATE a new user in the .htpasswd file, not
> > authenticate 'em. (After they create a userid they'll be asked to
> > login using regular HTTP authentication).  It was just a sample of a
> > modular design I'd like to see added to Embperl.  Read the
> > previous discussion again for details.  Maybe I wasn't clear.
> > 
> > This modular idea is useful for any instance where you need to get
> > form input from a person and validate it.


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web sites - is this possible? (was Re: Modular web site not behaving as expected.)

Posted by Wim Kerkhoff <wi...@merilus.com>.
Hi Scott,

I think I understand your point better now. I'm still convinced that it
is possible to do what you have described using EmbperlObject. 

Wim

Scott Chapman wrote:
> 
> Wim,
> I think you missed the point of our discussion. This isn't about
> authentication at all. It's about modular site design.  The web page
> I was talking about is just for getting a userid, password and email
> address to CREATE a new user in the .htpasswd file, not
> authenticate 'em. (After they create a userid they'll be asked to
> login using regular HTTP authentication).  It was just a sample of a
> modular design I'd like to see added to Embperl.  Read the
> previous discussion again for details.  Maybe I wasn't clear.
> 
> This modular idea is useful for any instance where you need to get
> form input from a person and validate it.

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web sites - is this possible? (was Re: Modular web site not behaving as expected.)

Posted by Scott Chapman <sc...@mischko.com>.
Wim,
I think you missed the point of our discussion. This isn't about 
authentication at all. It's about modular site design.  The web page 
I was talking about is just for getting a userid, password and email 
address to CREATE a new user in the .htpasswd file, not 
authenticate 'em. (After they create a userid they'll be asked to 
login using regular HTTP authentication).  It was just a sample of a 
modular design I'd like to see added to Embperl.  Read the 
previous discussion again for details.  Maybe I wasn't clear.

This modular idea is useful for any instance where you need to get 
form input from a person and validate it.

Cordially,
Scott



---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web sites - is this possible? (was Re: Modular web site not behaving as expected.)

Posted by Wim Kerkhoff <wi...@merilus.com>.
Scott Chapman wrote:
> 
> Neil,
> Thanks for the tip.

Aye!  That's a nice way of doing it.

> I'm already using Embperl Object quite a bit
> and intend to use it more.  Putting things in subs.epl is an option
> I'm using for some things but I don't want to put basically my entire
> modular site into subs.epl files.

He wasn't suggest that you do this -- only put your authentications
stuff into subs.epl.
 
> You hit it right on the head when you said I want it to be
> transparent.  This stateless environment is a continued amazement
> to me.  It's a wonder so much is being done with it when it has
> such design flaws.  Clearly, it is being used in ways it was not
> designed for.  The more modular it can be made the better for
> everyone involved (in development anway!).
> 
> Cordially,
> Scott
> 
> Neil wrote:
> > Of course what you are looking for is a way to make all this
> > transparent, which I can understand. But just throwing an idea out
> > there.

There is another alternative to transparent authentication and
authorization that we use all the time.

Follow Chapter 6 [1] of the mod_perl book [2], and write a
Apache::MyAuth handler that does the authentication/authorization. This
module would be written in pure perl. If they user is not logged in, use
HTML::Embperl::Execute to call your
header.html/loginform.html/footer.html, and return OK. If they are
logged in, return DECLINED so that the page can be loaded. This mod_perl
would be compiled at server startup time, and run *before* every request
that you specify. Ie, add it into httpd.conf/.htaccess via:

PerlAccessHandler Apache::MyAuth

While the EmbperlObject solution is nice way of doing it if you don't
feel like writing a mod_perl handler, I prefer this method. The handler
can be run before any request: plain CGI scripts, static HTML, images,
other handlers, whatever. If they login fails, the page isn't executed.
I find it a lot more reliable as well -- it's easier to add a bug in the
individual base.epl or subs.epl.

If you want to get fancy, you can use PerlSetVar, so that you can
control the authentication system (on/off, which users/groups, etc) on a
per directory/per file basis.

My last version of this used Apache::Session to store whether they were
logged in or not... this means that the auth handler can use the same
sessioning system as Embperl for maintaining state.

Just some more ideas... my $0.03 CDN.

1. http://www.modperl.com/book/chapters/ch6.html
2. http://www.modperl.com

-- 

Regards,

Wim Kerkhoff, Software Engineer
Merilus, Inc.  -|- http://www.merilus.com
Email: wim@merilus.com

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web sites - is this possible? (was Re: Modular web site not behaving as expected.)

Posted by Scott Chapman <sc...@mischko.com>.
Neil,
Thanks for the tip.  I'm already using Embperl Object quite a bit 
and intend to use it more.  Putting things in subs.epl is an option 
I'm using for some things but I don't want to put basically my entire 
modular site into subs.epl files.

You hit it right on the head when you said I want it to be 
transparent.  This stateless environment is a continued amazement 
to me.  It's a wonder so much is being done with it when it has 
such design flaws.  Clearly, it is being used in ways it was not 
designed for.  The more modular it can be made the better for 
everyone involved (in development anway!).

Cordially,
Scott

Neil wrote:
> Of course what you are looking for is a way to make all this
> transparent, which I can understand. But just throwing an idea out
> there.
 


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web sites - is this possible? (was Re: Modular web site not behaving as expected.)

Posted by Neil Gunton <ne...@nilspace.com>.
Scott Chapman wrote:
> This userid/password page is a module that I'd like to be able to
> drop into any project that needs this functionality.

Scott,

Just my two cents on your scenario...

You can achieve a high degree of modularity using EmbperlObject as it
stands. For instance, let's say you have a module which performs user
validation, as in your example. You can put this into a common library
area, say /www/lib/perl/. You then put some code in your base.epl file
(EMBPERL_OBJECT_BASE): (omitting obvious code)

/base.epl
  [-
    $subs = Execute ({object => 'subs.epl'});
    if (!$subs->handle())
    {
       Execute ({inputfile => '*', package => __PACKAGE__});
    }
  -]

/subs.epl
  [!
      sub handle
      {
         my ($self) = @_;
         return 0;
      }
  !]

So, by default the behavior is for handle() to return 0, which means
that the requested page ('*') will be called. Now, in a subdirectory
where you want to have your page handled by the module, you put a
subs.epl something like this:

/subdir/subs.epl
   [! Execute ({isa => '/www/lib/perl/Auth.epl'}) !]

You can then redefine the subroutine handle() in Auth.epl, so that it
does something (i.e. handles the request) and then returns 1. This gets
rid of the need for exit() in the way that you are describing, I think -
whenever you want to use a module, you simply make a subdirectory as a
'stub' for that module, and place a subs.epl like the one above there.
Then, you direct the browser to that location, and it will automatically
be handled by your module. For finer control, you could pass in as a
parameter to handle() the uri of the calling page. The handle() module
could then use this to construct the final destination, using a
redirect. An additional parameter could be passed to indicate a finer
level of granularity within the calling module. This parameter could
then be passed back to the original module from Auth.epl in a CGI
parameter, so that it's available in %fdat. This could then be used to
determine the current state.

Of course what you are looking for is a way to make all this
transparent, which I can understand. But just throwing an idea out
there.

HTH

-Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Modular web sites - is this possible? (was Re: Modular web site not behaving as expected.)

Posted by Scott Chapman <sc...@mischko.com>.
Gerald,

I've been giving a lot of thought to the idea of modular web pages 
and "exit" functionality is not nearly as nice as what I think you 
could build into embperl.

The problem is one of trying to create very modular web sites with 
resuable chuncks of code embodied in a web page that calls itself 
for data validation, etc. As an example, I have a page that presents 
some instructions and asks for the user to input their userid, 
password, and email address to create a new userid on the site.  It 
calls upon itself to do the data validation.  When the data is 
validated, it adds the userid to the .htpasswd file.

This userid/password page is a module that I'd like to be able to 
drop into any project that needs this functionality.  Problem with 
exit functionality:

When PageA executes this userid/password page (PageB) and it 
EXIT's at the bottom of the page, it does not return to PageA.  [So 
far so good.  I don't want PageA to be returned to until after the 
validation is done and the userid added.]  Next the user submits 
the data back to PageB. The conditionals in PageB make it so it 
checks the data rather than putting out the form again.  It is 
validated and the user is added to the .htpasswd file. Now the 
problem.  How do I get PageB to return to the line just following the 
calling line from PageA?  This should be just like calling a 
subroutine in Perl it should return to the next line when it's done.

It would be very nice to have Execute handle this with a parameter 
saying "Don't return here until you're told to by the page I'm 
calling".  PageB executes and at the end of PageB it automatically 
stops (like "exit" would do) but it keeps track of where it's 
supposed to return to internally like a regular subroutine would in a 
modular programming language.  When PageB finally executes a 
"return to calling page" command (perhaps passing parameters 
back like perls "return" statement), then and only then would 
PageB actually drop out the bottom and return to PageA.

I realize this is a stateless arena and implementing this would 
require some magic but think Embperl (and you) are able to make 
that kind of magic.  Is this possible or does the stateless nature of 
this make it impossible?  More modularity would be SO nice in this 
environment!

Cordially,
Scott

On 12 Nov 2001, at 10:06, Gerald Richter wrote:

> Scott,
> 
> Andrew have already given an excelent explanation, so there is not much to
> add...
> 
> >
> > Gerald, you want to build this functionality? :-)
> >
> 
> I am not sure which functionality you want to see here ? Just something like
> exit, that does not only exit the current file, but end the whole request ?
> In this case that's something what's on my todo list for 2.0. If you intent
> a more sophisticated thing, please try to explain it again, at the moment I
> understand your problem, but I don't see what EMbperl can do for you in this
> case ?
> 
> Gerald


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web site not behaving as expected.

Posted by Gerald Richter <ri...@ecos.de>.
> 
> When do you expect "exit" functionality to be in place?
> 

Should be in 2.0 in the next few weeks

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 925131
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web site not behaving as expected.

Posted by Scott Chapman <sc...@mischko.com>.
> > Gerald, you want to build this functionality? :-)
> 
> I am not sure which functionality you want to see here ? Just something like
> exit, that does not only exit the current file, but end the whole request ?
> In this case that's something what's on my todo list for 2.0. If you intent
> a more sophisticated thing, please try to explain it again, at the moment I
> understand your problem, but I don't see what EMbperl can do for you in this
> case ?

"Exit" functionality is one way of dealing with it and it would work.  

Another way to consider would be an Execute parameter that 
would say "Don't return here until you're explicitly told to".  Then a 
"Return with this data" or just "Return" statement to use in the 
called page saying "return to the calling page now".

When do you expect "exit" functionality to be in place?

Cordially,
Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web site not behaving as expected.

Posted by Gerald Richter <ri...@ecos.de>.
Scott,

Andrew have already given an excelent explanation, so there is not much to
add...

>
> Gerald, you want to build this functionality? :-)
>

I am not sure which functionality you want to see here ? Just something like
exit, that does not only exit the current file, but end the whole request ?
In this case that's something what's on my todo list for 2.0. If you intent
a more sophisticated thing, please try to explain it again, at the moment I
understand your problem, but I don't see what EMbperl can do for you in this
case ?

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 925131
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web site not behaving as expected.

Posted by Andrew O'Brien <an...@switchonline.com.au>.
On Sun, Nov 11, 2001 at 07:48:50PM -0800, Scott Chapman wrote:

> What I'm trying to accomplish here is to create a modular web site 
> where I can make completely reusable modules.  I want to make a 
> module, for instance, that allows a new user to sign up on the web 
> site and establish a new userid and password. This page, when 
> completed, will be able to be dropped into any web site I build where 
> I need this funcitonality.
> 
> So, I'm basically trying to implement very modular/object oriented 
> functionality in my web design.
> 
> I was hoping Embperl had a method of dealing with a sub-page as a 
> object that keeps control of the communication until it is
> completed.  

No - you will always have to do the glue logic. Unless I'm completely
missing the point :)

That understood, in a very real sense Execute is what you want
anyway. Each sub Execute is just like a module - it has inputs,
outputs and its own logic. The good thing is that most of the common
stuff *can* be abstracted out with EmbperlObject.

For example, there isn't much reason for the looping structure to be
included in every "module". It's essentially the same for all places
so why not have it as a single (overridable with EmbperlObject) epl
file that just takes an argument or calls a function to get the
current execution list.

> Problem is that it always falls right out of the called page back to the 
> calling page before I want it to.  This is an error in my design of the 
> called page.
> 
> The method you showed me below will work but I will actually have to 
> make it 3 layers deep.  Top layer is the calling page.  Second layer 
> is the looping structure.  Third layer is the web form functionality to 
> get the input from the user and show error messages and a "thank 
> you page" or whatever else is desired.  This way the second and 
> third layers go together to make a callable module.  I was hoping to 
> avoid this complexity because it is not as modular/object oriented as 
> I'd like it to be but that's the price you pay for dealing with this 
> stateless medium, unless Gerald has put some other magic into this 
> tool that I'm not aware of.
> 
> I really appreciate your reply and I'll build another layer in between 
> to take care of the looping.  If I could implement it as all one page, 
> I'd do so but it doesn't look like that is possible.  There doesn't 
> appear to be a "stop" function that prevents the calling page from 
> being returned to immediately.  

A call to "exit" will stop execution at that point in the
sub-execute and force a return to the parent. With the right
structure, this feature might be able to help you.

-- 
 Andrew O'Brien                                                               
 Product Engineer                        email: andrewo@switchonline.com.au.
 Switch Online Group Pty Limited         phone: +61 2 9299 1133             
 ABN 89 092 286 327                      fax: +61 2 9299 1134             

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web site not behaving as expected.

Posted by Scott Chapman <sc...@mischko.com>.
Andrew,

I am only too well aware of the stateless nature of this business (and 
it's a wonder people use it for real work as it is such a cludge - my 
low cost opinion :-).

What I'm trying to accomplish here is to create a modular web site 
where I can make completely reusable modules.  I want to make a 
module, for instance, that allows a new user to sign up on the web 
site and establish a new userid and password. This page, when 
completed, will be able to be dropped into any web site I build where 
I need this funcitonality.

So, I'm basically trying to implement very modular/object oriented 
functionality in my web design.

I was hoping Embperl had a method of dealing with a sub-page as a 
object that keeps control of the communication until it is completed.  
Problem is that it always falls right out of the called page back to the 
calling page before I want it to.  This is an error in my design of the 
called page.

The method you showed me below will work but I will actually have to 
make it 3 layers deep.  Top layer is the calling page.  Second layer 
is the looping structure.  Third layer is the web form functionality to 
get the input from the user and show error messages and a "thank 
you page" or whatever else is desired.  This way the second and 
third layers go together to make a callable module.  I was hoping to 
avoid this complexity because it is not as modular/object oriented as 
I'd like it to be but that's the price you pay for dealing with this 
stateless medium, unless Gerald has put some other magic into this 
tool that I'm not aware of.

I really appreciate your reply and I'll build another layer in between 
to take care of the looping.  If I could implement it as all one page, 
I'd do so but it doesn't look like that is possible.  There doesn't 
appear to be a "stop" function that prevents the calling page from 
being returned to immediately.  

Gerald, you want to build this functionality? :-)

Cordially,
Scott

On 12 Nov 2001, at 10:33, Andrew O'Brien wrote:

.... lots of useful information that I snipped ....  :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web site not behaving as expected.

Posted by Andrew O'Brien <an...@switchonline.com.au>.
On Fri, Nov 09, 2001 at 07:27:54AM -0800, Scott Chapman wrote:
> Below I've included the top page and the page that it executes. 
> 
> What I want is for the page that it executes to not return to the 
> main page until I tell it to. See comments in the code below. 

Scott,

You're completely missing one of the fundamental points of web
programming: http is a stateless protocol. This means that each web
page you see is the result of a request to a web server (optionally
with other input, like POST or GET data) which spits out a hunk of
headers and HTML back at you. Thats it. There's no more "state"
between your browser and the server - its a one shot deal.

Using Embperl sessions and so on is something different, but only
because embperl does all the work setting up the environment before
your code gets to it *every single time* a request comes in.

In the context of your below code, here's how things should be
happening. This is a standard sequence of ecents that becomes VERY
familiar if you're writing CGI scripts or similar:

1. browser sends a request to http://my.site/blah.html
2. The page blah.html executes from the top, checks to see if there is
   any form input:
   NO - generates the first form page and then exits.
3. browser receives web page, user fills it in and hits submit.
4. The web page blah.html receives the request, executes from the top,
   checks to see if there is any form input:
   YES - identifies it as the respose from form page N, processes the
   answers. If all OK then prints out form page N+1, else prints out
   form page N with error messages or something.
5. Go to 3

Because each request is "from scratch" you need to have some way of
identifying the individual pages from the browser's response. One
common way is to use hidden fields in your forms.

Your main page becomes a whole lot of "if" statements. A state
machine, if you like. I hope this has made things clearer.


A useful structure if you've got a whole sequence of forms which takes
advantage of executing into a buffer. This just checks a return code
from the execute'd file. A return code of 1 means that there was form
input and it checked out OK, unchanged means that there either wasn't
form input or there was and there was an error.

---------------
main.html:
[-
$page = get_users_page(); # get from %udat or from a database somwhere
                          # else or from %fdat, even. Trusting %fdat
                          # is not recommended!

$done = 0;
do {
  if ($done) {
    $page = get_users_next_page();
    $done = 0;
    undef %fdat; # clean up for next execute
  }
  Execute( { inputfile => "$page",
             output => \$buffer,
             param = [ \$done ] } );
} until (!$done)
-]
[$ if keys %fdat $]
Here is some error text for the page, if needed
[$ endif $]
[+ local $escmode = 0; $buffer +]

---------------
some_random_form_page.epl:

[- $req = shift;
 $ref_to_done = $param[0];
 if (keys %fdat) {    # note: I have optAllFormData on
   #process stuff
   if (no errors) {
     $$ref_to_done = 1; # set $done to true
   }
 }
-]
rest of page goes here
---------------

> > [-
> > 
> >     Execute ({inputfile => 'test_form.epl',
> >           fdat      => \%fdat,
> >           ffld      => \@ffld});
> > 
> > # The following code should not be executed immediately after 
> > # executing the test_form.epl page.  The test_form.epl page 
> > # should not return to here until after the "elsif" is executed 
> > # on that page.
> >
> >     print (OUT "Page: $fdat{page}<P>");
> > 
> 
> Here's the sub page. It's a sample of the mechanism that would be 
> used to do a data entry form with validation. 
> 
> 
> > <HTML>
> > <HEAD>
> > <TITLE>TEST FORM</TITLE>
> > </HEAD>
> > <BODY>
> > 
> > [$ if $fdat{page} == 0 $]
> > # Data entry section would go here, presenting a form to the user.
> > Page = 0<P>
> >    <form action="test_form.epl" method="POST">
> >         <input type="hidden" name="page" value="1">
> >         <input type="submit" name="cancel" value="Page = 1"></p>
> >    </form>
> > 
> > [$ elsif $fdat{page} == 1 $] 
> > # Data checking by the server would go here and would present a 
> > # form button to the user allowing them to submit the data a final 
> > # time after they confirmed it was right and the server did it's 
> > # confirmation.
> > Page = 1<P>
> >    <form action="test_form.epl" method="POST">
> >         <input type="hidden" name="page" value="2">
> >         <input type="submit" name="cancel" value="Page = 2"></p>
> >    </form>
> > 
> > [$ elsif  $]
> > # After the user submits the final form, return to the calling page.
> > Page = 2<P>
> > 
> > [$endif$]
> > 
> > </BODY>
> > </HTML>
> 
> 
> 
> On 9 Nov 2001, at 7:14, Gerald Richter wrote: 
> 
> 
> > > I am trying to build a web site out of standalone pages that are
> > > called from a top level page.
> > >
> > > When I call a sub-page, they return immediately.  How do I prevent
> > > this.
> > >
> > > For instance, I have a main page that looks like this:
> > >
> > 
> > I am not quite sure, that I understand what you mean. Normaly a sub-page
> > will only return when it has processed it's code, unless you call it with
> > the import parameter, in this case only the [! !] blocks will be executed.
> > Maybe you can give a short real Perl example
> > 
> > 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 925131
> > WWW:        http://www.ecos.de      Fax:      +49 6133 925152
> > -------------------------------------------------------------
> > 
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> > For additional commands, e-mail: embperl-help@perl.apache.org
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
> 

-- 
 Andrew O'Brien                                                               
 Product Engineer                        email: andrewo@switchonline.com.au.
 Switch Online Group Pty Limited         phone: +61 2 9299 1133             
 ABN 89 092 286 327                      fax: +61 2 9299 1134             

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web site not behaving as expected.

Posted by Scott Chapman <sc...@mischko.com>.
Below I've included the top page and the page that it executes. 

What I want is for the page that it executes to not return to the 
main page until I tell it to. See comments in the code below. 

> [-
> 
>     Execute ({inputfile => 'test_form.epl',
>           fdat      => \%fdat,
>           ffld      => \@ffld});
> 
> # The following code should not be executed immediately after 
> # executing the test_form.epl page.  The test_form.epl page 
> # should not return to here until after the "elsif" is executed 
> # on that page.
>
>     print (OUT "Page: $fdat{page}<P>");
> 

Here's the sub page. It's a sample of the mechanism that would be 
used to do a data entry form with validation. 


> <HTML>
> <HEAD>
> <TITLE>TEST FORM</TITLE>
> </HEAD>
> <BODY>
> 
> [$ if $fdat{page} == 0 $]
> # Data entry section would go here, presenting a form to the user.
> Page = 0<P>
>    <form action="test_form.epl" method="POST">
>         <input type="hidden" name="page" value="1">
>         <input type="submit" name="cancel" value="Page = 1"></p>
>    </form>
> 
> [$ elsif $fdat{page} == 1 $] 
> # Data checking by the server would go here and would present a 
> # form button to the user allowing them to submit the data a final 
> # time after they confirmed it was right and the server did it's 
> # confirmation.
> Page = 1<P>
>    <form action="test_form.epl" method="POST">
>         <input type="hidden" name="page" value="2">
>         <input type="submit" name="cancel" value="Page = 2"></p>
>    </form>
> 
> [$ elsif  $]
> # After the user submits the final form, return to the calling page.
> Page = 2<P>
> 
> [$endif$]
> 
> </BODY>
> </HTML>



On 9 Nov 2001, at 7:14, Gerald Richter wrote: 


> > I am trying to build a web site out of standalone pages that are
> > called from a top level page.
> >
> > When I call a sub-page, they return immediately.  How do I prevent
> > this.
> >
> > For instance, I have a main page that looks like this:
> >
> 
> I am not quite sure, that I understand what you mean. Normaly a sub-page
> will only return when it has processed it's code, unless you call it with
> the import parameter, in this case only the [! !] blocks will be executed.
> Maybe you can give a short real Perl example
> 
> 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 925131
> WWW:        http://www.ecos.de      Fax:      +49 6133 925152
> -------------------------------------------------------------
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Re: Modular web site not behaving as expected.

Posted by Gerald Richter <ri...@ecos.de>.
> I am trying to build a web site out of standalone pages that are
> called from a top level page.
>
> When I call a sub-page, they return immediately.  How do I prevent
> this.
>
> For instance, I have a main page that looks like this:
>

I am not quite sure, that I understand what you mean. Normaly a sub-page
will only return when it has processed it's code, unless you call it with
the import parameter, in this case only the [! !] blocks will be executed.
Maybe you can give a short real Perl example

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 925131
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------




---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org