Re: [Pas-dev] include files

[Mental <Me...@Ne...>]

On Thu, Feb 28, 2002 at 10:33:31AM -0500, Kyle R . Burton wrote:
> 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.
> 
> 

Having it in an external .dep file will make writing an ant clone easier.
This way we can do that idea about precompiling all the pages on a site
pre-release. This way the webserver NEVER has write access ANYWHERE
important. Like I said before, compiling on the fly for dev is fine, but
in a production environment, why would you want that? Youd want to release
a prebuilt production release. Anyways... yeah. I think a metadata file
for includes (and perhaps other stuff as it comes up) is a good idea.

> 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.
> 

Fair enough. 

> > 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?
> 

$self->__ ? :)

> Well, that's one option at least.  
> 
>   <!-- page1.psp -->
>   <% return $self->forward_request('page2.psp'); %>
> 
> ...
> 
<SNIP>

Personally, I will always have $self->forward_request('/path/to/psp');

Yes. Its double edged, however no matter how you do it, if you move stuff
around its a lot of maintenence. 

> 
> 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).
> 

The docroot and pasroot are one and the same for me. :)



--
Mental (Me...@Ne...)

Ever notice how irons have a setting for *permanent* press?  I
don't get it...
--Steven Wright

GPG public key: http://www.neverlight.com/Mental.asc