pas-dev

[Pas-dev] include files

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

I'm in the process of 'fixing' include files. 

Problem: When you include a file in a psp and up date the included file,
but not the psp, the page doesnt rebuild.

Proposed solution: Each compiled object should have a $page->__includes()
method that returns a list of its includes (suprise). After a page's
timestamp is compared to the psp, the timestamps on the includes are
checked. If any of these are newer than the page, the compiler rebuilds
the page. 

I plan on making this check configuraable in teh config file. IF someone
feels all these stat()/date checks are too expensive, they can turn them
off. :)


Hopefully I'll have more time tonight to track this down.

Next on my TODO list is figuring out why it takes 2 refreshes to see the
rebuilt page. This isnt a big deal, but it still nerves me.  

THe only reason I'm sending this is because if I dont brain dump now, I
might forget later. :)

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

It too close to my house.  I was
walking from the living room to the kitchen, and the stewardess
told me to sit down.
--Steven Wright

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

Re: [Pas-dev] include files]

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

On Thu, Feb 28, 2002 at 09:57:16AM -0500, Kyle R . Burton wrote:
> At this point, the compiler could probably use a re-write (the code isn't
> the prettiest).  Perhaps we should back down on the policy of few to no
> external dependencies and base the compiler on HTML::Parser?  I'm sure
> it would end up being a whole lot cleaner and more extensible.  In fact
> using HTML::Parser would probably allow us to start the process of moving
> towards JSP style taglibs.
> 

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. 

> Some other things I've noticed working with Pas lately are that $self->prev()
> doesn't seem to be working correctly.  Since it's not part of the servlet
> model, maybe we just get rid of it?  
> 

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

> Passing data to the psp from a Page object in the query object is starting 
> to feel wrong.  The issue that caused this to itch for me was on a diagnostics
> page where I was trying to dump all of the parameters from the query.  I
> had a page object that added data to the query, then forwarded the request
> to the psp diagnostic page.  In the psp page, it had code like this:
> 
>   <TABLE>
>     <TR><TD>key</TD><TD>value</TD></TR>
>   <% foreach my $k ($self->query()->param()) { %>
>     <TR><TD><%= $k %></TD><TD><%= $self->query()->param($k) %></TD></TR>
>   <% } %>
>   </TABLE>
>     

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

> But the added data didn't show up in the key names returend from
> $self->query()->param().  CGI.pm must be caching the originaly parsed
> list of parameters - anything that get's added through a call to param(k,v)
> isn't included in the list returned by param().  
> 
> Perhaps we can use the reuqest object directly?  Ala the servlet model?
> They have a getParameter() that gives access to the GET/POST parameters,
> and a getAttribute()/setAttribute() that is a storage area where the
> servlet/jsp (page object/psp in our case) are supposed to use to pass 
> data back and forth.
> 

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.

> The last big itch is in the forward_request() method of the page object.  It
> doesn't seem to work with relativly pathed requests correctly.  I've had
> to tweak the path to the psp page to get it to work under all circumstances.
> Oh, and one last thing is PATH_INFO for registered page objects.  It would
> be nice of the Pas mod_perl request handler could figure out that a path
> lead past a registered page object, and set the PATH_INFO accordingly.
> 
> I'll add this stuf to the TODO file.
> 

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.


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

There was a power outage at a department store yesterday.
Twenty people were trapped on the escalators.
--Steven Wright

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

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

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