This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: [Mason] $m->file bug? From: "Eric Windisch" <eric@site5.com> To: <mason-users@lists.sourceforge.net> Date: Fri, 13 Dec 2002 15:05:33 -0500 (EST) > http://devel.grokthis.net/test.txt > http://devel.grokthis.net/text-bad.txt If you didn't pick it up already.. that should be: http://devel.grokthis.net/test-bad.txt I have to start double-checking links :) -- Eric Windisch ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users === To: "Eric Windisch" <eric@site5.com>, <mason-users@lists.sourceforge.net> From: Alex Robinson <alexr@cloudband.com> Subject: Re: [Mason] $m->file() bug? Date: Fri, 13 Dec 2002 20:47:33 +0000 >http://devel.grokthis.net/test.txt etc It's not $m->file() which is causing the component to be compiled - it's the fact that you are calling it directly as a top level component. Just because your autohandler says to ignore processing the component if it's one of various types is irrelevant since top level components must get run through Mason to check that the autohandler has not been overridden. Consequently, if your file is not "valid" Mason, it will fall over. You could use a dhandler so that the files are not called directly (and you could then store the files wherever) and then your code would work with little modification. Alternatively you could, and probably should, handle this kind of stuff in your handler. ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users === Subject: Re: [Mason] $m->file bug? From: "Eric Windisch" <eric@site5.com> To: <mason-users@lists.sourceforge.net> Date: Fri, 13 Dec 2002 18:17:01 -0500 (EST) >>http://devel.grokthis.net/test.txt etc > > It's not $m->file() which is causing the component to be compiled - it's the fact that you are calling it directly as a top level component. Just because your autohandler says to ignore processing the component if it's one of various types is irrelevant since top level components must get run > through Mason to check that the autohandler has not been overridden. This explaination doesn't seem to 'jive'. With your explaination, an error should be the result by the following change: - print $m->file($next->source_file)' + print "<%"; However, this does not result in a parse error.. it prints <% into the resulting document. This implies that the parse-error is happening from within the execution of $m->file(); -- Eric Windisch ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users === Subject: Re: [Mason] $m->file bug? From: "Eric Windisch" <eric@site5.com> To: <mason-users@lists.sourceforge.net> Date: Fri, 13 Dec 2002 19:26:09 -0500 (EST) > This explaination doesn't seem to 'jive'. With your explaination, an error should be the result by the following change: > > - print $m->file($next->source_file)' > + print "<%"; Hmm.. maybe you were right. Odd. Surely, shouldn't the autohandler be executed first and then load the component(s) necessary? I could call a component from the web, but have the autohandler IGNORE the component and call another component. In such an example this would cause the ignored component to still be passed through the Lexer! I'd hardly call that efficient (even if it is, for some reason, necessary). My only assumption for this is that Mason loads the component, looks for 'parents' (such as autohandlers).. then it executes the parents, which in turn are assumed to execute the component. It also sounds as if any component with is sucessfully passed through the autohandler in a 'normal' fashion, is run through the Lexer twice (first when the component is loaded, then when the autohandler calls it). Would that not be so? It looks like I should examine this (mason's) code throughly :) -- Eric Windisch ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users === From: Dave Rolsky <autarch@urth.org> To: Eric Windisch <eric@site5.com> Subject: Re: [Mason] $m->file bug? Date: Fri, 13 Dec 2002 18:36:16 -0600 (CST) On Fri, 13 Dec 2002, Eric Windisch wrote: > Surely, shouldn't the autohandler be executed first and then load the > component(s) necessary? I could call a component from the web, but have No, we have to load the component being called to make check to see if it set a parent flag. You should use a dhandler for what you're doing. > My only assumption for this is that Mason loads the component, looks for > 'parents' (such as autohandlers).. then it executes the parents, which in > turn are assumed to execute the component. > > It also sounds as if any component with is sucessfully passed through the > autohandler in a 'normal' fashion, is run through the Lexer twice (first > when the component is loaded, then when the autohandler calls it). Would > that not be so? No, that's not correct. -dave /*================== www.urth.org we await the New Sun ==================*/ ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users === To: "Eric Windisch" <eric@site5.com>, mason-users@lists.sourceforge.net From: Alex Robinson <alexr@cloudband.com> Subject: Re: [Mason] $m->file bug? Date: Sat, 14 Dec 2002 01:14:51 +0000 >> - print $m->file($next->source_file)' >> + print "<%"; > >Hmm.. maybe you were right. Odd. I suspect you moved the "<%" from your top level component to the autohandler, meaning that the tlc was now actually ok. >Surely, shouldn't the autohandler be executed first and then load the >component(s) necessary? No. Because the top level component (and any intervening autohandlers) has the right to step in and override which (if any) autohandler to use. <http://www.masonhq.com/docs/manual/Devel.html#_flags_> <http://www.masonhq.com/docs/manual/Devel.html#objectoriented_techniques> >I could call a component from the web, but have >the autohandler IGNORE the component and call another component. In such >an example this would cause the ignored component to still be passed >through the Lexer! I'd hardly call that efficient (even if it is, for >some reason, necessary). Maybe. But I'd say that that would be the fault of your design, not Mason's. Either use a dhandler or else have your handler not invoke Mason at all for these files. >It also sounds as if any component with is sucessfully passed through the >autohandler in a 'normal' fashion, is run through the Lexer twice (first >when the component is loaded, then when the autohandler calls it). Would >that not be so? I'm not so sure about that. Once the component is loaded, it doesn't need to be loaded or lexxorred again. >It looks like I should examine this (mason's) code throughly :) Nope. Just read the documentation thoroughly. ;) ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users === From: Dave Rolsky <autarch@urth.org> To: Eric Windisch <eric@site5.com> Subject: Re: [Mason] $m->file bug? Date: Fri, 13 Dec 2002 19:19:34 -0600 (CST) On Fri, 13 Dec 2002, Eric Windisch wrote: > But the dhandler is only executed in the case that a requested component > doesn't exist.... so I couldn't reference the files directly. Personally, > I think using a dhandler here would overvalue the definition of 'cheap, > dirty hack'. > > A solution may be to ignore any errors found in the loading of the > requested file. If the file parses fine, check for a parent flag.. if it > gives an error, ignore the error and assume it has specified no parents. That's an even cheaper, dirtier hack! Look, you told Mason to serve "file x". Don't get upset when it chokes! If you don't want to use a dhandler, just make a "servethis" component that takes the real file's url/filename as an argument. -dave /*================== www.urth.org we await the New Sun ==================*/ ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users === Subject: Re: [Mason] $m->file bug? From: "Eric Windisch" <eric@site5.com> To: <mason-users@lists.sourceforge.net> Date: Fri, 13 Dec 2002 20:22:43 -0500 (EST) > No, we have to load the component being called to make check to see if it > set a parent flag. You should use a dhandler for what you're doing. But the dhandler is only executed in the case that a requested component doesn't exist.... so I couldn't reference the files directly. Personally, I think using a dhandler here would overvalue the definition of 'cheap, dirty hack'. A solution may be to ignore any errors found in the loading of the requested file. If the file parses fine, check for a parent flag.. if it gives an error, ignore the error and assume it has specified no parents. -- Eric Windisch ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users === Subject: Re: [Mason] $m->file bug? From: "Eric Windisch" <eric@site5.com> To: <alexr@cloudband.com> Cc: <mason-users@lists.sourceforge.net> Date: Fri, 13 Dec 2002 20:50:53 -0500 (EST) >>Surely, shouldn't the autohandler be executed first and then load the >>component(s) necessary? > > No. Because the top level component (and any intervening autohandlers) has > the right to step in and override which (if any) autohandler to use. Well, I understand what happens now. Mason loads the requested file and reads the parent/inheritance flag, if it exists. This parent flag determines who the parents (and hence, the autohandlers) are. > Maybe. But I'd say that that would be the fault of your design, not > Mason's. Either use a dhandler or else have your handler not invoke Mason > at all for these files. dhandlers work for files that aren't found. These files need to be referenced by their physical paths. Mason needs to be invoked for these files because I'm using multiple component roots. The error I'm recieving is a parse error during the loading of the component for the sake of checking the parent flag. However, since this is for the sake of determining the autohandler.. I think the best solution would be for Mason to ignore the error of loading the component and passing it to the 'default' autohandler (treat it as a component which didn't specify an inheritance/parent flag). I assume that without loading the component you cannot have a $m->fetch_next() would have to return NULL.. but that shouldn't be a problem as long as the filename can be obtained by some function or variable. -- Eric Windisch ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users === From: Dave Rolsky <autarch@urth.org> To: Eric Windisch <eric@site5.com> Subject: Re: [Mason] $m->file bug? Date: Fri, 13 Dec 2002 22:51:03 -0600 (CST) On Fri, 13 Dec 2002, Eric Windisch wrote: > The error I'm recieving is a parse error during the loading of the > component for the sake of checking the parent flag. However, since this > is for the sake of determining the autohandler.. I think the best solution > would be for Mason to ignore the error of loading the component and > passing it to the 'default' autohandler (treat it as a component which > didn't specify an inheritance/parent flag). That just doesn't make sense. For _most_ people, an error when parsing a component is worth knowing about, and we're not going to stop reporting those errors, period. -dave /*================== www.urth.org we await the New Sun ==================*/ ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users === Subject: Re: [Mason] $m->file bug? From: "Eric Windisch" <eric@site5.com> To: <mason-users@lists.sourceforge.net> Date: Sat, 14 Dec 2002 13:22:39 -0500 (EST) > That just doesn't make sense. For _most_ people, an error when parsing a > component is worth knowing about, and we're not going to stop reporting > those errors, period. My suggest was to report errors, but only to report them when the component is executed.. not at load-time (at least not when executed transparently by Mason). I did resort to using a dhandler. I put all of my files into a subdirectory of my comp_root and then used the dhandler to run .html files as subrequests and everything else was passed through without being interpretted. After figuring out how to utilize the resolver, it wasn't so bad. It is a bit of a kludge, but it works well. -- Eric Windisch ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users === From: Dave Rolsky <autarch@urth.org> To: Eric Windisch <eric@site5.com> Subject: Re: [Mason] $m->file bug? Date: Sat, 14 Dec 2002 12:27:24 -0600 (CST) On Sat, 14 Dec 2002, Eric Windisch wrote: > > That just doesn't make sense. For _most_ people, an error when parsing > a > > component is worth knowing about, and we're not going to stop reporting > > those errors, period. > > My suggest was to report errors, but only to report them when the > component is executed.. not at load-time (at least not when executed > transparently by Mason). That wouldn't work. We need to compile the component when it's loaded in order to get things like flags and such. > I did resort to using a dhandler. I put all of my files into a > subdirectory of my comp_root and then used the dhandler to run .html > files as subrequests and everything else was passed through without being > interpretted. After figuring out how to utilize the resolver, it wasn't > so bad. It is a bit of a kludge, but it works well. You could probably serve the .html files directly and just change your URLs for the non-HTML files. Something like /serve-via-dhandler/foo.avi Then you just have a /serve-via-dhandler/dhandler file. -dave /*================== www.urth.org we await the New Sun ==================*/ ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users