symfony 1.3

[Jack Bates]

in revision 4145 i updated to symfony 1.3 - but i haven't quite
finished yet

in the meantime use,

$ svn up -r 4144 lib/vendor/symfony

^ to continue using symfony 1.2

[Jack Bates]

so i've updated most of the project to work with symfony 1.3 - as
david just pointed out in the chat room, this means rolling back lib/
vendor/symfony won't work anymore because, e.g. lib/model/map now
works only with symfony 1.3

$ svn up -r 4144 lib/vendor/symfony lib/model/map

^ does this work in the meantime?

[David Juhasz]

On 14-Dec-09, at 4:20 PM, Jack Bates wrote:

> so i've updated most of the project to work with symfony 1.3 - as
> david just pointed out in the chat room, this means rolling back lib/
> vendor/symfony won't work anymore because, e.g. lib/model/map now
> works only with symfony 1.3
>
> $ svn up -r 4144 lib/vendor/symfony lib/model/map
>
> ^ does this work in the meantime?
>

This doesn't seem to work as I test it now with r4180...

---
The filter name "common" is defined in "/Applications/MAMP/htdocs/
qubit/lib/vendor/symfony/lib/config/config/filters.yml" but not
present in "/Applications/MAMP/htdocs/qubit/apps/qubit/config/
filters.yml" file. To disable a filter, add a "enabled" key with a
false value.
--

Using the trunk version without reverting the above directories to
r4144 seems to be almost working. The main problem I'm having now is
that the routing rules don't retain the dev front-controller name - so
if I'm at:

http://localhost/~david/qubit/web/qubit_dev.php/object/importSelect

and click the "Import" button, I end up at:

http://localhost/~david/qubit/web/object/import

With a "White screen of Death" and no debugging info. :(



David Juhasz,
Software Engineer, Artefactual Systems Inc.
http://www.artefactual.com | P: 604.527.2056 | F: 604.521.2059

[Jack Bates]

On Dec 15, 2:21 pm, David Juhasz <da...@artefactual.com> wrote:
> Using the trunk version without reverting the above directories to  
> r4144 seems to be almost working.  The main problem I'm having now is  
> that the routing rules don't retain the dev front-controller name - so  
> if I'm at:
>
> http://localhost/~david/qubit/web/qubit_dev.php/object/importSelect
>
> and click the "Import" button, I end up at:
>
> http://localhost/~david/qubit/web/object/import
>
> With a "White screen of Death" and no debugging info. :(

awesome - thanks david - looking into it now...

[Jack Bates]

aha - i think i found the problem - if you,

$ cp apps/qubit/config/settings.yml{.tmpl,}

- does that fix the problem?

[David Juhasz]

On 18-Dec-09, at 9:47 AM, Jack Bates wrote:

aha - i think i found the problem - if you,

$ cp apps/qubit/config/settings.yml{.tmpl,}

- does that fix the problem?

Yes, that fixes the problem with the developement front controller "sticking".  Still hitting the Fatal error:

Fatal error: Class 'fbISO639_Map' not found in /Applications/MAMP/htdocs/qubit/lib/QubitXmlImport.class.php on line 179

[David Juhasz]

On 21-Dec-09, at 9:03 AM, David Juhasz wrote:

Yes, that fixes the problem with the developement front controller "sticking".  Still hitting the Fatal error:

Fatal error: Class 'fbISO639_Map' not found in /Applications/MAMP/htdocs/qubit/lib/QubitXmlImport.class.php on line 179

See issue #1157:

http://code.google.com/p/qubit-toolkit/issues/detail?id=1157

[Peter Van Garderen]

>
> Yes, that fixes the problem with the developement front controller
> "sticking". Still hitting the Fatal error:
>
>

> *Fatal error*: Class 'fbISO639_Map' not found in
> */Applications/MAMP/htdocs/qubit/lib/QubitXmlImport.class.php* on line *179*
>

I'm hitting similar '*Map* not found' fatal errors in a few places.

informationobject/show/isad (in the sidebar component slot):

Fatal error: Class 'ActorI18nMapBuilder' not found in
/home/peter/public_html/qubit/lib/QubitCultureFallback.class.php(41) : eval()'d
code on line 1

actor/show/isaar/ (in the sidebar component slot):

Fatal error: Class 'InformationObjectI18nMapBuilder' not found in
/home/peter/public_html/qubit/lib/QubitCultureFallback.class.php(41) : eval()'d
code on line 1

If I disable the sidebar component slot, I hit the following error on
informationobject/edit/isad

Fatal error: Class 'TermI18nMapBuilder' not found in
/home/peter/public_html/qubit/lib/QubitCultureFallback.class.php(41) : eval()'d
code on line 1

And the same on actor/edit/isaar

Fatal error: Class 'TermI18nMapBuilder' not found in
/home/peter/public_html/qubit/lib/QubitCultureFallback.class.php(41) : eval()'d
code on line 1

This is holding me back from testing Validation. Any work around suggestions?

--peter

[Jack Bates]

i think it's because of this change in propel,
http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4/WhatsNew#MapBuildersaregone

does this workaround avoid the problem temporarily?
http://www.sfu.ca/~jdbates/tmp/qubit/200912220/patch

[Jesús García Crespo]

Hi Jack,

> does this workaround avoid the problem temporarily?
> http://www.sfu.ca/~jdbates/tmp/qubit/200912220/patch

It works here.

Thank you,

--
Jesús García Crespo

[Peter Van Garderen]

Yes, works. Thanks Jack. Also need to apply it to lib/model/QubitActor.php. See
attached patch.

--peter

> --
>
> You received this message because you are subscribed to the Google Groups "Qubit Toolkit Developers" group.
> To post to this group, send email to qubi...@googlegroups.com.
> To unsubscribe from this group, send email to qubit-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/qubit-dev?hl=en.
>
>
>

[Peter Van Garderen]

in the Term module there's lots of "Fatal error: Class 'TaxonomyI18nMapBuilder'

not found in
/home/peter/public_html/qubit/lib/QubitCultureFallback.class.php(41) : eval()'d
code on line 1"

As per our existing patches, I tried commenting out a few calls that added
Fallback to criteria but this only produces a number of other (i.e. missing
columns) errors.

It seems like this particular issues keeps coming back to
lib/QubitCultureFallback.class.php which explicitly calls the MapBuilder classes
that were deprecated in Symfony 1.3/Propel 1.4

Can someone suggest a patch for this set of Fatal errors in the Term module or a
schedule to fix/upgrade QubitCultureFallback specifically? I'm concerned that we
have these holes at least patched up in time for the next code review (Jan4) so
that the reviewers don't encounter any unnecessary Fatal errors as they work
their way through the app.

--peter

[Jesús García Crespo]

Hi Peter,

On Wed, Dec 23, 2009 at 7:09 PM, Peter Van Garderen
<pe...@artefactual.com> wrote:
> Can someone suggest a patch for this set of Fatal errors in the Term module or a
> schedule to fix/upgrade QubitCultureFallback specifically? I'm concerned that we
> have these holes at least patched up in time for the next code review (Jan4) so
> that the reviewers don't encounter any unnecessary Fatal errors as they work
> their way through the app.

See attached patch. It works here.

Regards,

--
Jesús García Crespo

[Jack Bates]

fantastic! i think you patch corrects all the QubitCultureFallback
errors

david - can you please double check this patch is correct? if so, i
think you should go ahead and commit, jesus : )

[David at Artefactual]

On Dec 27, 11:16 am, Jack Bates <jack.ba...@gmail.com> wrote:
> david - can you please double check this patch is correct? if so, i
> think you should go ahead and commit, jesus : )

Looks good to me, make it so number 1!

D