the Doctrine::preInsert is an event listener. And no matter how you
code it it's still going to break. Basically my Member class needs
to check user session before any inserts whether they come from a real
session or from loading fixtures. No matter where this goes, I must
check the user session on fixture loading (or else create code that
checks if I am coming from a task or real session which would be
silly). And I don't know of a way to access the session without
loading the context.
On Apr 26, 7:11 pm, Jonathan Wage <[EMAIL PROTECTED]> wrote:
> That is what I mean, in my opinion I wouldn't ever have my data models
> hardcoded to rely on them being used in the context of a symfony
> application. It is mixing layers which shouldn't be mixed. Doing so
> renders your models useless if they aren't used in a symfony
> application. I would recommend using an event listener you attach to
> the model in the application that sets the data from the session on
> insert.
>
> On Apr 26, 2008, at 4:38 PM, Amadeus <[EMAIL PROTECTED]> wrote:
>
>
>
> > In this case, I have a class Member that on insert, adds contextual
> > information from the user session. I modified the task system to load
> > a configuration which works but it's a hack. In my opinion one should
> > be able to load fixtures regardless of how the code is written.
>
> > On Apr 26, 2:22 pm, Jonathan Wage <[EMAIL PROTECTED]> wrote:
> >> My opinion is that your models should not be tied to the context of a
> >> symfony application.
>
> >> On Apr 26, 2008, at 4:06 PM, Amadeus <[EMAIL PROTECTED]> wrote:
>
> >>> Evidently you cannot call sfcontext from a task. This is an issue as
> >>> the fixture load is bound to call code where this is used. Changing
> >>> that code to just work for task loading doesn't make sense so the
> >>> task
> >>> system is going to need a mechanism to deal with this.
>
> >>> On Apr 26, 1:30 pm, Dustin Whittle <[EMAIL PROTECTED]
> >>> project.com> wrote:
> >>>> Amadeus,
>
> >>>> Make sure to upgrade to the 1.1 plugin for doctrine. The problem is
> >>>> that you
> >>>> no longer get the first context, but rather create a context with
> >>>> configuration.
>
> >>>> $configuration = sfApplicationConfiguration::getForApplication
> >>>> ('frontend',
> >>>> 'dev', true)
>
> >>>> $context = sfContext::createInstance($configuration);
>
> >>>> - Dustin
>
> >>>> On 4/26/08 12:08 PM, "Amadeus" <[EMAIL PROTECTED]> wrote:
>
> >>>>> I'm getting this error now after my final upgrade. I get it
> >>>>> when I
> >>>>> call "symfony doctrine:load-data public". It comes from one of my
> >>>>> Doctrine classes which has a preInsert method with the line:
> >>>>> $geo
> >>>>> = sfContext::getInstance()->getUser()->getAttribute('geo');
>
> >>>>> Any ideas?
>
> >>>>> On Apr 16, 4:10 am, angelsk <[EMAIL PROTECTED]> wrote:
> >>>>>> Hi,
>
> >>>>>> I keep getting this error message when trying to run some of the
> >>>>>> symfony commands. I'm sure I'm missing something important,
> >>>>>> config-
> >>>>>> wise, but no idea what.
>
> >>>>>> [EMAIL PROTECTED] trunk]$ php symfony propel:data-load --append
> >>>>>> frontend
>
> >>>>>>>> propel load data from "/mnt/homes/jcar...opping.com/trunk/
> >>>>>>>> data/fixtures"
>
> >>>>>> The "default"contextdoes not exist.
>
> >>>>>> The fixtures folder contains village-data.yml
>
> >>>>>> Also, got the same error trying to generate-crud for the village
> >>>>>> class
> >>>>>> on the frontend.
>
> >>>>>> Any ideas what I'm missing, anyone else come across the same
> >>>>>> problem?
>
> >>>>>> Thanks
>
> >>>>>> Jo
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
