Re: [Pas-dev] include files

[Kyle R . B. <mo...@vo...>]

> At this point I'm actually doing stuff. So I plan on patching up the
> compiler first. We can do the rewrite as a phase 2. Actually, we could
> start the rewrite now as I've forked off my own version of pas for my use.
> Still, I dont think it'd take me long to fix up includes stuff so I might
> as well do it as an interim fix. 

Yeah, the best thing I think we can do to solve this is to have the compiler
track all the dependant files and put them into the compiled page object:

  ...
  use strict;
  use warnings;
  use Org::Bgw::Pas::Page;
  our @ISA = qw( Org::Bgw::Pas::Page );
  our @DEPS = qw( file1.psp file2.psp file3.psp );
  ...

Then the compile can "eval { use $package; };" and then get at the dependency
array.  I think that is a better solution than making it a method on the
page object itself - the reason is so the compiler doesn't have to instantiate
an instance of the page object before it can compile it.  Hrm...that raises
another issue - what if the psp has compile time errors in it (typos)?

What about storing dependency data seperate from the generated PageObject.pm
file?  Maybe in a mirror file called PageObject.deps?  It could just be a 
list of the psp pages that went into it...That way the compile wouldn't have
to look at any of the compiled page object's code, so it wouldnt matter
how broken up it was, the dependency data would all be external - and maybe
faster for the compiler to access too.


> Just because it isnt part of the servlet model doesnt mean its not a good
> idea. The servlet model has its own shortcomings. I just got done helping
> Kevin sort out some stuff that I feel was a shortcoming of the whole
> servlet thing. I'd go into it, but its long, I forget most of the details
>  and I'm busy.  :)

Yeah, for the MEL project we spent the bulk of the design time getting
around the anti-OO nature of the servlet model.  It was annoying, but by
the time we finished comming up with the page model, it felt just about
the same as Pas.

> Wouldnt the stuff you wanted to see be in $self->prev()?
> Shouldnt it be? Am I not getting it?

Sort of.  You could access a get/set from the prev() page object.  The
idea is to pass data to the psp page for it to display.  If it has access
to methods on the prev() page object, it gets coupled (tied) to the interface
of that page object -- which keeps you from forwarding to that particular
psp from some other page object.  Does that make sense?  So it's better
to have it pull it's data from some stash instead of from methods directly
on the prev() page.  

Actualy, after saying that, I'm now settled on the descision - we're going
to remove prev() from Pas.  It encourages coupling between the page objects
and the psp pages, which is bad OO.

> In my mind it might be a good idea to keep our stuff in its own sandbox.
> That way we cna differentiate between stuff we inserted and stuff that the
> browser passed. I'm not sur ethe best way to do this, but it could be
> something like $self->query() is for cgi.pm stuff (the browser post/get
> crud). Something ike $self->pasdata() could be used for stuff te
> application generates and uses internally. There would be no way for the
> browser to get its evil into it and could therfore be more trusted to
> contain 'good' data. Segregate user input from application generated
> stuff. Or maybe I should stop huffing paint.

That's a great point.  Keeping applicaiton data away from get/post data
is a good seperation paradigm.  As to where we store it, we should try
to come up with a data object (just a get/set storage container, with
a design similar to the session - dumb key/value pair storage) that is
used for passing that kind of data.  One nice thing about that, mod_perl,
and the request handler is that we can make that storage object global
for the http request itself.

But what do we call it that will be clear and make sense?

> I'll have ot play with forwrd_requst a little to see what you mean. It
> might not be a bad idea to forward to fully pathed uri's anyways. At least
> from a paranoid insecure standpoint. But that could just be me
> misundersanding sometihg I'm unfamiliar with.

Well, that's one option at least.  

  <!-- page1.psp -->
  <% return $self->forward_request('page2.psp'); %>

...

  <!-- page2.psp in same directory as page1.psp -->
  <% return $self->forward_request('../page3.psp'); %>

...
 
  <!-- page3.psp one directory up from page[12].psp -->
  <% return $self->forward_request('foo/page4.psp'); %>

...
 
  <!-- page4.psp one directory down from page[3].psp -->
  <% return $self->forward_request('/page5.psp'); %>

...

  <!-- page5.psp in the application's or document root -->


I think all those examples sum up all of the ways a forward can
be invoked.  I am of the opinion that all of those should work.
The last one raises the issue of the Pas document root vs the
web server's doc root.  Which one is at '/' for the purposes
of forwarding?  Currently '/' is the Pas doc root for forwarding,
and '/' is the webservers doc root for the purposes of http redirection 
(http 302 responses).



k

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------