Thank you. I ended up inserting a throw at the point I wanted.
There is a severe error in sfFinder that requires an immediate fix.
No one seems interested in it so far...
.Joe
On Apr 1, 3:13 am, Georg Sorst <[EMAIL PROTECTED]> wrote:
> Hey Joe,
>
> I can't help you with the problem itself, but figuring out what
> variables are set to what values at which point just asks for a debugger
> instead of trying to figure it out from the code :) That way you could
> also check the values in $files whenever you like.
>
> Cheers,
> Georg
>
> Joe Kelsey schrieb:
>
> > Since type() is the only static-declared member of sfFinder, it
> > clearly needs calling first in the chain. Then,
> > ignorm_version_control and relative each set internal sfFinder members
> > to control return values. Finally, in will generate a list of files
> > and use the settings of ignore_version_control and relative to
> > supposedly produce the correct list. I think that in does not
> > generate relative paths due to the value of DIRECTORY_SEPARATOR. I
> > suspect that some combination foreaddir() and windoze confusion is
> > causing this failure. Can anyone provide assistance here? How do I
> > make it stop in sfCrudGenerator so I can verify the values in $files?
>
> > /Joe
>
> > On Mar 31, 10:08 am, Joe Kelsey <[EMAIL PROTECTED]> wrote:
> >> Searching up the calling chain, in sfCrudGenerator, generate calls
> >> this:
>
> >> $files = sfFinder::type('file')->ignore_version_control()-
>
> >>> relative()->in($themeDir);
> >> It then passes the resulting array $files to$this->generatePhpFiles,
> >> which shows and array of fully-qualified path names, whereas the
> >> calling program obviously wanted relative path names due to the
> >> existence of the relative() qualifier in its calling chain. However,
> >> the mere existence of the relative() call does not produce the result
> >> intended due to the calling sequence. I think the sequence should be
> >> in($themeDir)->relative() because the relative qualifier has to be set
> >> before generating the result, not after. Am I correct? In this case
> >> shouldn't the whole sequence of calls be reversed?
>
> >> /Joe
>
> >> On Mar 31, 9:50 am, Joe Kelsey <[EMAIL PROTECTED]> wrote:
>
> >>> So, getGeneratorTemplate takes three parameters, the $class, the
> >>> $theme and the $template. The string passed as $template is a fully-
> >>> qualified path, which on windoze includes the disk name. You then
> >>> collect a set of directories representing the directories to look in,
> >>> also including fully-qualified path names, and you attempt to form a
> >>> path name by appending the fully-qualified template path name to the
> >>> fully-qualified directory path name and apply is_readable to this
> >>> abomination of a path. Of course, this will never work!
> >>> What exactly SHOULD you do here? take the last two portions of the
> >>> template file name (actions/actions.class.php) and apply it to the
> >>> directory name? Take simply the last portion of the template and
> >>> apply it? What exactly is the correct thing to do? Move further up
> >>> the calling chain and determin where exactly to trim the template name
> >>> being passed down?
> >>> Inquiring minds want to know!
> >>> /Joe
> >>> On Mar 31, 8:42 am, Joe Kelsey <[EMAIL PROTECTED]> wrote:
> >>>> After examining the code, I can see two problems.
> >>>> 1) The value of $path is a full path, ending with actions.class.php.
> >>>> There is not way fo $dir.'/'.$path to form any sort of viable path
> >>>> name.
> >>>> 2/ The $dir value ends one directory too soon. The default/template
> >>>> directory contains a single subdirectory, templates which contains the
> >>>> generated php files.
> >>>> How do we resolve these two issues? Whic part of the code is magic?
> >>>> Does somepthing magically combine the two path names so that they make
> >>>> sense? Does something magically include the templates directory
> >>>> contents? What am I missing?
> >>>> /Joe
> >>>> On Mar 31, 7:59 am, Joe Kelsey <[EMAIL PROTECTED]> wrote:
> >>>>> I have gone through all of the listed steps required to generate an
> >>>>> admin screen to no avail. I have done the following
> >>>>> symfony generate:project osw
> >>>>> symfony generate:app admin
> >>>>> build the schema.yml
> >>>>> symfony propel:init-admin admin type Type
> >>>>> Then when I try to visit admin_dev.php/type I get:
> >>>>> [sfException]
> >>>>> Unable to load "C:\PHP\pear\symfony\lib\plugins\sfPropelPlugin\data
> >>>>> \generator\sfPropelAdmin\default\template\actions\actions.class.php"
> >>>>> generator template in: C:\Documents and Settings\josephk\osw\data/
> >>>>> generator/sfPropelAdmin/default/template, C:\PHP\pear\symfony\lib/
> >>>>> plugins/sfPropelPlugin/data/generator/sfPropelAdmin/default/template.
> >>>>> There is nothing in my data directory. Should there be a generator
> >>>>> directory already created there? I am puzzled.
> >>>>> /Joe
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
