sfShop and sf1.4

[Florian]

Hi devs,

Do someboody implemented a propel behavior to port old sfsPeerBuilder
to the new propel Behavior system?

I'm trying to port sfShop to 1.4, so if anybody does the same,
please tell me!

Here is the list of the project:validate task :

1. Checking usage of deprecated classes

25 file(s) need to be changed.
ROOT/plugins/sfsDeliveryFedexPlugin/lib/sfsFedexService.class.php
sfLoader
ROOT/plugins/sfsAddressBookPlugin/lib/model/AddressBookPeer.php
sfLoader
ROOT/plugins/sfsAddressBookPlugin/modules/addressBook/lib/
BaseAddressBookActions.class.php
sfLoader
ROOT/plugins/sfsMemberPlugin/modules/member/lib/
BaseMemberActions.class.php
sfLoader
ROOT/plugins/sfsOrderPlugin/modules/order/lib/
BaseOrderActions.class.php
sfLoader
ROOT/plugins/sfsInstallPlugin/modules/installer/lib/
BaseInstallerActions.class.php
sfLoader
ROOT/plugins/sfsProductPlugin/lib/model/BrandPeer.php
sfLoader
ROOT/plugins/sfsProductPlugin/lib/form/ProductForm.class.php
sfWidgetFormChoiceMany
ROOT/plugins/sfsProductPlugin/lib/form/
sfsProductOptionsForm.class.php
sfLoader
ROOT/plugins/sfsProductPlugin/modules/productAdmin/lib/
BaseProductAdminActions.class.php
sfLoader
ROOT/plugins/sfsProductPlugin/modules/product/lib/
BaseProductActions.class.php
sfLoader
ROOT/plugins/sfsPaymentCMCICPlugin/modules/cmcic/lib/
BaseCmcicActions.class.php
sfLoader
ROOT/plugins/sfsBasketPlugin/modules/basket/lib/
BaseBasketActions.class.php
sfLoader
ROOT/plugins/sfSearchPlugin/data/generator/sfSearchInterface/default/
template/actions/components.class.php
sfLoader
ROOT/plugins/sfsCorePlugin/lib/propel/builder/SfsPeerBuilder.php
SfPeerBuilder
ROOT/plugins/sfsPaymentAuthorizeNetPlugin/modules/authorizeNet/lib/
BaseAuthorizeNetActions.class.php
sfLoader
ROOT/plugins/sfsDeliveryUpsPlugin/lib/form/
sfsUpsParamsForm.class.php
sfValidatorChoiceMany
ROOT/plugins/sfsDeliveryUpsPlugin/lib/sfsUpsService.class.php
sfLoader
ROOT/plugins/sfsCategoryPlugin/modules/categoryAdmin/lib/
BaseCategoryAdminActions.class.php
sfLoader
ROOT/plugins/sfsCategoryPlugin/modules/categoryAdmin/lib/
BaseCategoryAdminComponents.class.php
sfLoader
ROOT/plugins/sfsCategoryPlugin/modules/category/lib/
BaseCategoryComponents.class.php
sfLoader
ROOT/plugins/sfsPaymentWebmoneyPlugin/modules/webmoney/lib/
BaseWebmoneyActions.class.php
sfLoader
ROOT/plugins/sfsDeliveryPlugin/modules/delivery/lib/
BaseDeliveryActions.class.php
sfLoader
ROOT/plugins/sfsPaymentPlugin/lib/action/sfsPaymentAction.class.php
sfLoader
ROOT/plugins/sfsPaymentPlugin/modules/payment/lib/
BasePaymentActions.class.php
sfLoader

The files above use deprecated classes
that have been removed in symfony 1.4.

You can find a list of all deprecated classes under the
"Classes" section of the DEPRECATED tutorial:

http://www.symfony-project.org/tutorial/1_4/en/deprecated

2. Checking usage of deprecated configuration files

4 file(s) need to be changed.
ROOT/plugins/sfsCurrencyPlugin/modules/currencyAdmin/validate/
edit.yml
ROOT/plugins/sfsMemberPlugin/modules/memberAdmin/validate/edit.yml
ROOT/plugins/sfsProductPlugin/modules/optionTypeAdmin/validate/
edit.yml
ROOT/plugins/sfsProductPlugin/modules/optionValueAdmin/validate/
edit.yml

The project uses deprecated configuration files
that have been removed in symfony 1.4 (mailer.yml, validate/*.yml)
or for which the format changed (generator.yml)

3. Checking usage of deprecated helpers

4 file(s) need to be changed.
ROOT/plugins/sfsOrderPlugin/modules/orderAdmin/templates/
_filter_member_full_name.php
input_tag
ROOT/plugins/sfsOrderPlugin/modules/orderAdmin/templates/
detailsSuccess.php
submit_tag
ROOT/plugins/sfsProductPlugin/modules/productAdmin/templates/
_editOptionsListForm.php
options_for_select, select_tag, input_tag, checkbox_tag
ROOT/plugins/sfsProductPlugin/modules/productAdmin/templates/
_addOptionValueForm.php
input_tag, input_hidden_tag, label_for

The files above use deprecated helpers
that have been removed in symfony 1.4.

You can find a list of all deprecated helpers under the
"Helpers" section of the DEPRECATED tutorial:

http://www.symfony-project.org/tutorial/1_4/en/deprecated

4. Checking usage of deprecated methods

4 file(s) need to be changed.
ROOT/test/functional/frontend/currencyActionsTest.php
isRequestParameter, checkResponseElement
ROOT/test/functional/frontend/deliveryActionsTest.php
isRequestParameter, checkResponseElement
ROOT/test/functional/frontend/odflActionsTest.php
isRequestParameter, checkResponseElement
ROOT/test/functional/frontend/fedexActionsTest.php
isRequestParameter, checkResponseElement

The files above use deprecated functions and/or methods
that have been removed in symfony 1.4.

You can find a list of all deprecated methods under the
"Methods and Functions" section of the DEPRECATED tutorial:

http://www.symfony-project.org/tutorial/1_4/en/deprecated

5. Checking usage of deprecated plugins

OK

6. Checking usage of deprecated settings

OK

7. Checking usage of array notation with a parameter holder

9 file(s) need to be changed.
ROOT/plugins/sfsAddressBookPlugin/modules/addressBook/templates/
editSuccess.php
ROOT/plugins/sfsAddressBookPlugin/modules/addressBook/lib/
BaseAddressBookActions.class.php
ROOT/plugins/sfsMemberPlugin/lib/validator/
sfsValidatorMember.class.php
ROOT/plugins/sfsMemberPlugin/modules/member/lib/
BaseMemberActions.class.php
ROOT/plugins/sfsProductPlugin/modules/productAdmin/lib/
BaseProductAdminActions.class.php
ROOT/plugins/sfsProductPlugin/modules/product/lib/
BaseProductActions.class.php
ROOT/plugins/sfsCurrencyPlugin/modules/currency/lib/
BaseCurrencyActions.class.php
ROOT/plugins/sfsBasketPlugin/modules/basket/lib/
BaseBasketActions.class.php
ROOT/plugins/sfsCorePlugin/lib/validator/sfsValidatorAdmin.class.php

The files above use the array notation with a parameter holder,
which is not supported anymore in symfony 1.4.
For instance, you need to change this construct:

$foo = $request->getParameter('foo[bar]')

to this one:

$params = $request->getParameter('foo')
$foo = $params['bar'])

[Andreas Nyholm]

Hi.

I do not think anybody is porting sfShop to 1.4 at the moment. You are
welcome to help with that. Let me know if you need assistance. Please
create a 1.4 branch for this.

Regards,
Andreas

[Florian]

Hi Andreas,

Thanks for the answer!
Ok I'll create a 1.4 branch and then implement the SfsBehavior.

Did you already had to use new propel behaviors ? It's different from
the old method,
and for the moment I tried without success.

[Andreas Nyholm]

Hi.

No I have not. I've used Doctrine for recent projects. What do you think
about a change to doctrine for 1.4 version? If the propel change is not
so simple it's worth thinking about.

/Andreas

Florian wrote:
> Hi Andreas,
>
> Thanks for the answer!
> Ok I'll create a 1.4 branch and then implement the SfsBehavior.
>
> Did you already had to use new propel behaviors ? It's different from
> the old method,
> and for the moment I tried without success.
>

[Florian]

Ok,

me too, I switched to Doctrine, but an ORM port can be hard to do...

but I know Propel 1.5 is not so bad, so maybe why not use it?

Just for info, Diem switched from propel to Doctrine since it's last
beta:

if they can do it, why couldn't we? :)

Cheers, Florian.

[Andreas Nyholm]

I took a look at some of the plugins and most ORM specific code is in
the model. Of the external plugins it's only search that's using ORM.
Are there anything I've been missing that have different principles in
propel and doctrine and would take lot of time.

Thinking of future I think a change would be best. More and more plugins
are doctrine only. The question is, now or wait a year for sf2.0?

What do you think? What amount of time will you be able to put into
sfshop in near future?

/Andreas

[Florian]

Hi,

sorry for this late response!
You're right, most of the work is done in final model classes, but in
module's actions too!

here is a list of files where Criteria API is used:

plugins/sfsAddressBookPlugin/lib/model/AddressBook.php:37:new Criteria
plugins/sfsAddressBookPlugin/lib/model/AddressBook.php:42:new Criteria
plugins/sfsAddressBookPlugin/lib/model/AddressBookPeer.php:51:new Criteria
plugins/sfsAddressBookPlugin/lib/model/AddressBookPeer.php:91:new Criteria
plugins/sfsAddressBookPlugin/lib/model/AddressBookPeer.php:107:new Criteria
plugins/sfsAddressBookPlugin/lib/model/AddressFormatPeer.php:36:new Criteria
plugins/sfsAddressBookPlugin/lib/model/AddressFormatPeer.php:55:new Criteria
plugins/sfsBasketPlugin/lib/model/Basket.php:28:new Criteria
plugins/sfsBasketPlugin/lib/model/BasketProductPeer.php:33:new Criteria
plugins/sfsBasketPlugin/lib/model/BasketProductPeer.php:54:new Criteria
plugins/sfsBasketPlugin/lib/model/BasketProductPeer.php:80:new Criteria
plugins/sfsBasketPlugin/lib/model/BasketPeer.php:37:new Criteria
plugins/sfsBasketPlugin/lib/model/BasketProduct2OptionProductPeer.php:33:new
Criteria
plugins/sfsCategoryPlugin/lib/model/CategoryPeer.php:35:new Criteria
plugins/sfsCategoryPlugin/lib/model/CategoryPeer.php:101:new Criteria
plugins/sfsCategoryPlugin/lib/model/CategoryPeer.php:106:new Criteria
plugins/sfsCategoryPlugin/lib/model/CategoryPeer.php:109:new Criteria
plugins/sfsCategoryPlugin/lib/model/CategoryPeer.php:118:new Criteria
plugins/sfsCategoryPlugin/lib/model/CategoryPeer.php:150:new Criteria
plugins/sfsCategoryPlugin/lib/model/CategoryPeer.php:153:new Criteria
plugins/sfsCategoryPlugin/lib/model/CategoryPeer.php:176:new Criteria
plugins/sfsCategoryPlugin/lib/model/CategoryPeer.php:179:new Criteria
plugins/sfsCategoryPlugin/lib/model/CategoryPeer.php:198:new Criteria
plugins/sfsCategoryPlugin/lib/model/CategoryPeer.php:199:new Criteria
plugins/sfsCategoryPlugin/lib/model/Category.php:53:new Criteria
plugins/sfsCorePlugin/lib/model/admin/AdminMenuPeer.php:14:new Criteria
plugins/sfsCorePlugin/lib/model/admin/AdminMenuPeer.php:18:new Criteria
plugins/sfsCorePlugin/lib/model/admin/AdminMenuPeer.php:34:new Criteria
plugins/sfsCorePlugin/lib/model/admin/AdminPeer.php:32:new Criteria
plugins/sfsCorePlugin/lib/model/common/AssetTypePeer.php:22:new Criteria
plugins/sfsCorePlugin/lib/model/common/MenuPeer.php:28:new Criteria
plugins/sfsCorePlugin/lib/model/common/EmailTemplatePeer.php:28:new Criteria
plugins/sfsCorePlugin/lib/model/common/CountryPeer.php:14:new Criteria
plugins/sfsCorePlugin/lib/model/common/LanguagePeer.php:32:new Criteria
plugins/sfsCorePlugin/lib/model/common/LanguagePeer.php:49:new Criteria
plugins/sfsCorePlugin/lib/model/common/StatePeer.php:15:new Criteria
plugins/sfsCurrencyPlugin/lib/model/CurrencyPeer.php:25:new Criteria
plugins/sfsCurrencyPlugin/lib/model/CurrencyPeer.php:43:new Criteria
plugins/sfsCurrencyPlugin/lib/model/CurrencyPeer.php:59:new Criteria
plugins/sfsCurrencyPlugin/lib/model/CurrencyPeer.php:89:new Criteria
plugins/sfsMemberPlugin/lib/model/MemberPeer.php:28:new Criteria
plugins/sfsMemberPlugin/lib/model/MemberPeer.php:46:new Criteria
plugins/sfsOrderPlugin/lib/model/OrderProductPeer.php:22:new Criteria
plugins/sfsOrderPlugin/lib/model/OrderItemPeer.php:22:new Criteria
plugins/sfsOrderPlugin/lib/model/OrderStatusPeer.php:38:new Criteria
plugins/sfsPaymentPlugin/lib/model/PaymentPeer.php:22:new Criteria
plugins/sfsProductPlugin/lib/model/OptionProduct.php:21:new Criteria
plugins/sfsProductPlugin/lib/model/Product.php:44:new Criteria
plugins/sfsProductPlugin/lib/model/Product.php:58:new Criteria
plugins/sfsProductPlugin/lib/model/Product.php:72:new Criteria
plugins/sfsProductPlugin/lib/model/OptionValuePeer.php:33:new Criteria
plugins/sfsProductPlugin/lib/model/OptionValuePeer.php:51:new Criteria
plugins/sfsProductPlugin/lib/model/OptionValuePeer.php:54:new Criteria
plugins/sfsProductPlugin/lib/model/Product2CategoryPeer.php:22:new Criteria
plugins/sfsProductPlugin/lib/model/ProductPeer.php:23:new Criteria
plugins/sfsProductPlugin/lib/model/ProductPeer.php:46:new Criteria
plugins/sfsProductPlugin/lib/model/ProductPeer.php:49:new Criteria
plugins/sfsProductPlugin/lib/model/ProductPeer.php:65:new Criteria
plugins/sfsProductPlugin/lib/model/BrandPeer.php:26:new Criteria
plugins/sfsProductPlugin/lib/model/BrandPeer.php:27:new Criteria
plugins/sfsProductPlugin/lib/model/OptionProductPeer.php:26:new Criteria
plugins/sfsTaxPlugin/lib/model/plugin/PluginTaxRatePeer.php:54:new Criteria
plugins/sfsTaxPlugin/lib/model/plugin/PluginTaxTypePeer.php:14:new Criteria
plugins/sfsTaxPlugin/lib/model/plugin/PluginTaxTypePeer.php:30:new Criteria
plugins/sfsThumbnailPlugin/lib/model/ThumbnailMimePeer.php:22:new Criteria
plugins/sfsThumbnailPlugin/lib/model/Thumbnail.php:40:new Criteria
plugins/sfsThumbnailPlugin/lib/model/ThumbnailTypeAssetTypePeer.php:22:new
Criteria
plugins/sfsThumbnailPlugin/lib/model/ThumbnailTypeAssetTypePeer.php:37:new
Criteria
plugins/sfsThumbnailPlugin/lib/model/ThumbnailPeer.php:28:new Criteria
plugins/sfsThumbnailPlugin/lib/model/ThumbnailPeer.php:46:new Criteria
plugins/sfsThumbnailPlugin/lib/model/ThumbnailPeer.php:59:new Criteria
plugins/sfsThumbnailPlugin/lib/model/ThumbnailPeer.php:89:new Criteria
plugins/sfsThumbnailPlugin/lib/model/ThumbnailPeer.php:127:new Criteria
plugins/sfsAddressBookPlugin/modules/addressBook/lib/BaseAddressBookActions.class.php:33:new
Criteria
plugins/sfsBasketPlugin/modules/basket/lib/BaseBasketActions.class.php:195:new
Criteria
plugins/sfsCategoryPlugin/modules/categoryAdmin/lib/BaseCategoryAdminComponents.class.php:41:new
Criteria
plugins/sfsCategoryPlugin/modules/categoryAdmin/lib/BaseCategoryAdminComponents.class.php:69:new
Criteria
plugins/sfsCategoryPlugin/modules/categoryAdmin/lib/BaseCategoryAdminComponents.class.php:75:new
Criteria
plugins/sfsCorePlugin/modules/core/lib/BaseCoreComponents.class.php:24:new
Criteria
plugins/sfsCorePlugin/modules/core/lib/BaseCoreActions.class.php:32:new
Criteria
plugins/sfsCorePlugin/modules/administratorAdmin/lib/BaseAdministratorAdminActions.class.php:56:new
Criteria
plugins/sfsCorePlugin/modules/languageAdmin/lib/BaseLanguageAdminActions.class.php:59:new
Criteria
plugins/sfsCorePlugin/modules/languageAdmin/lib/BaseLanguageAdminActions.class.php:116:new
Criteria
plugins/sfsCorePlugin/modules/information/lib/BaseInformationActions.class.php:24:new
Criteria
plugins/sfsCorePlugin/modules/information/lib/BaseInformationComponents.class.php:24:new
Criteria
plugins/sfsCurrencyPlugin/modules/currencyAdmin/lib/BaseCurrencyAdminActions.class.php:43:new
Criteria
plugins/sfsDeliveryPlugin/modules/delivery/lib/BaseDeliveryComponents.class.php:41:new
Criteria
plugins/sfsDeliveryPlugin/modules/delivery/lib/BaseDeliveryComponents.class.php:70:new
Criteria
plugins/sfsDeliveryPlugin/modules/delivery/lib/BaseDeliveryComponents.class.php:80:new
Criteria
plugins/sfsDeliveryPlugin/modules/deliveryAdmin/lib/BaseDeliveryAdminComponents.class.php:32:new
Criteria
plugins/sfsDeliveryPlugin/modules/deliveryAdmin/lib/BaseDeliveryAdminActions.class.php:57:new
Criteria
plugins/sfsDeliveryPlugin/modules/deliveryAdmin/lib/BaseDeliveryAdminActions.class.php:101:new
Criteria
plugins/sfsMemberPlugin/modules/member/lib/BaseMemberActions.class.php:46:new
Criteria
plugins/sfsMemberPlugin/modules/member/lib/BaseMemberActions.class.php:258:new
Criteria
plugins/sfsMemberPlugin/modules/memberAdmin/lib/BaseMemberAdminActions.class.php:39:new
Criteria
plugins/sfsOrderPlugin/modules/order/lib/BaseOrderComponents.class.php:32:new
Criteria
plugins/sfsOrderPlugin/modules/order/lib/BaseOrderActions.class.php:230:new
Criteria
plugins/sfsOrderPlugin/modules/order/lib/BaseOrderActions.class.php:248:new
Criteria
plugins/sfsOrderPlugin/modules/order/lib/BaseOrderActions.class.php:271:new
Criteria
plugins/sfsPaymentPlugin/modules/payment/lib/BasePaymentComponents.class.php:36:new
Criteria
plugins/sfsPaymentPlugin/modules/paymentAdmin/lib/BasePaymentAdminComponents.class.php:31:new
Criteria
plugins/sfsPaymentPlugin/modules/paymentAdmin/lib/BasePaymentAdminActions.class.php:57:new
Criteria
plugins/sfsPaymentPlugin/modules/paymentAdmin/lib/BasePaymentAdminActions.class.php:101:new
Criteria
plugins/sfsProductPlugin/modules/brand/lib/BaseBrandComponents.class.php:24:new
Criteria
plugins/sfsProductPlugin/modules/optionValueAdmin/lib/BaseOptionValueAdminActions.class.php:39:new
Criteria
plugins/sfsProductPlugin/modules/productAdmin/lib/BaseProductAdminComponents.class.php:42:new
Criteria
plugins/sfsProductPlugin/modules/productAdmin/lib/BaseProductAdminComponents.class.php:59:new
Criteria
plugins/sfsProductPlugin/modules/productAdmin/lib/BaseProductAdminComponents.class.php:71:new
Criteria
plugins/sfsProductPlugin/modules/productAdmin/lib/BaseProductAdminComponents.class.php:98:new
Criteria
plugins/sfsProductPlugin/modules/optionTypeAdmin/lib/BaseOptionTypeAdminActions.class.php:41:new
Criteria
plugins/sfsProductPlugin/modules/product/lib/BaseProductActions.class.php:53:new
Criteria
plugins/sfsProductPlugin/modules/product/lib/BaseProductActions.class.php:90:new
Criteria

That makes a lo(ooo)ng list where we have to change all ORM specific code!
What do you think of that ?

I don't think we should wait for Symfony 2, even if it's first demo is
near :) :
http://www.symfony-project.org/blog/2010/02/12/it-is-getting-near-some-symfony-live-information

there is the Doctrine2 option too...

And finally, to answer your last question, I can invest a little time in
sfShop, but it is additional to my work.
But, I heard my chief talk about sfshop ( he's maybe intersted, and if
so we will work on it !).

/Florian

Le 12/02/2010 07:45, Andreas Nyholm a �crit :

[Andreas Nyholm]

Hi.

You're right, that's a quite long list :) I think it's better to keep
propel and make a successful migration to 1.4 than a change to Doctrine
that might not be finished by lack of time. Do what you feel most
comfortable with. :)

As a side note I have also seen some interest here so I think I will be
able to do some work on sfShop in near future. I'll focus on other parts
and we can merge our work later. It's great if we can see some activity
on sfShop again! :)

/Andreas

[Alexandru Emil Lupu]

HI!
i have joined this list soon, and i would like to contribute as well.
I have worked with sf 1.0, 1.2, 1.4, but as well with Doctrine and
Propel.
I have proposed to Dimitry to make a new project and migrate it to
Doctrine.
Yes, i know, ... is hard to maintain 1 project, but is harder to
maintain 2 projects (2 bug lists, 2 feature request lists, and so
on...).
I will start to take that list that is upper and i will try to make
the project work on Sf 1.4 and Doctrine. I will make a closed project
of it for the moment, and afterwards, after i get Dimitry's consent, i
will make it public, and i will let the people the chance to add some
contributions.

I don't want to split the list, or so, but i think that this open
project could be usefull for Doctrine developers as well.

Alecs

On Feb 16, 9:16 pm, Andreas Nyholm <nyholmsoluti...@gmail.com> wrote:
> Hi.
>

> ...
>
> read more »

[Andreas Nyholm]

Hi Alecs!

Thank you for offering your help. But I do not think you need to make a
new project for a Doctrine version. As far as I know I'm the only one
using sfShop in production and I do not mind migrating to doctrine as
long as the database stays intact (or with minor changes).

What about you Florian, how far have you made it with the 1.4 migration?
Can you and Alecs work together on a 1.4 version? Do you mind using
Doctrine if Alecs is up to Doctrine specific work.

One change I would like to do at some point is to replace current user
handling with sfGuard. Now might be a good time?

Everybody:
If someone else is using sfShop and need to keep the propel version
please speak now :)

Also I would be interested to hear if someone else is using sfShop.
Other ideas, comments about sfShop?

What I think is most important is getting some work done, there have not
been much work on sfShop the last year. The question about ORM is
second. As I mentioned in my last mail, it's better to do some real
improvments on sfShop with Propel, than a migration to Doctrine that
never get finished.

Regards,
Andreas

[Alexandru-Emil Lupu]

Hi!

I have tried to run sfshop on propel, as i have some experience with it as well ... but, unfortunatelly, i have saw a lot of problems on the current project (new install), so i would like to fix them one by one.

I will try to make a list of the things that needs to be fixed due to php deprecations or due to sf ones.

Meanwhile i will wait for someone to gimme some developer / commiter rights on the project, and i will start to work with who wants to fix or migrate the project to sf 1.4 and doctrine 1.2.1

Alecs

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

--
Have a nice day!

Alecs
Certified ScrumMaster

There are no cannibals alive! I have ate the last one yesterday ...  
I am on web:  http://www.alecslupu.ro/
I am on twitter: http://twitter.com/alecslupu
I am on linkedIn: http://www.linkedin.com/in/alecslupu
Tel: (+4)0722 621 280

[Andreas Nyholm]

Hi.

I have added you to the project.

My current setup is that I created my own base project about a year ago
from sfShop. Since then I have only synced my project with the sfShop
plugins, since I'm using my own layout and some minor modifications. So
there might be some issues when creating a new project regarding config
files (and other things I missed). It's great if you are able to
document and fix any issues you might find. Btw, I have never used the
install app, if you are trying that part.

Let's see what Florian has to say. But I think it's best if you do
development in a branch, either Florians 1.4 branch or a new doctrine
branch. When a more stable version is ready we can move code to trunk.

Plese let me know about the progress. If there are anything unclear just
ask. What do you think, should we add all important plugins into one
main plugin, like Sympal?

Regards,
Andreas

> <mailto:nyholmsoluti...@gmail.com>> wrote:
>
> Hi.
>
> You're right, that's a quite long list :) I think it's
> better to keep
> propel and make a successful migration to 1.4 than a change
> toDoctrine
> that might not be finished by lack of time. Do what you feel
> most
> comfortable with. :)
>
> As a side note I have also seen some interest here so I
> think I will be
> able to do some work on sfShop in near future. I'll focus on
> other parts
> and we can merge our work later. It's great if we can see
> some activity
> on sfShop again! :)
>
> /Andreas
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "sfshop" group.
> To post to this group, send email to sfs...@googlegroups.com

> <mailto:sfs...@googlegroups.com>.

> To unsubscribe from this group, send email to
> sfshop+un...@googlegroups.com

> <mailto:sfshop%2Bunsu...@googlegroups.com>.

[Alexandru-Emil Lupu]

HI!
it would be great if we would be able to make a simple plugin (more like sympal) it would be easier to work with and also would be easier to install the project on an existing project, or a new one.
I will try to ticket all the errors i can find ... and after that i will try to fix one by one, as i want to use this platform on a project (maybe more) ...

I know that the installer is pretty much down ... It creates a wrong DSN + somethimes (all the times) missundertand the $password post...


Alecs

[Florian]

Hi,

sorry not to give news, but we are working on a 1.4 branch in the
background,
it seems to work but need more changes
before a commit on the 1.4 branch of the sfShop repository.

Florian.

[Florian]

oups, miss to say we still use propel1.4 for the moment.

[Andreas Nyholm]

Ok. Please add a ticket to the installer: Do not use! :)

We can later create a installer like Sympal and Diem.

/Andreas

> <mailto:nyholms...@gmail.com

> <mailto:nyholmsoluti...@gmail.com

> <mailto:sfs...@googlegroups.com

> <mailto:sfs...@googlegroups.com>>.
>
> To unsubscribe from this group, send email to
> sfshop+un...@googlegroups.com
> <mailto:sfshop%2Bunsu...@googlegroups.com>

> <mailto:sfshop%2Bunsu...@googlegroups.com
> <mailto:sfshop%252Buns...@googlegroups.com>>.

[Andreas Nyholm]

Ok. Can you give some info on what parts/plugins have changed except for
propel specific changes?

/Andreas

[Alexandru-Emil Lupu]

HI Florian!

Please commit into 1.4 branch what you have worked.
I will update my repo to use the 1.4 branch, and after that, i will start to add some improvements to that code... even it is using propel.
After we make the project 1.4 compatible (we elude those deprecated stuff), i will make a doctrine branch and, rewrite the queries.

Andreas, i have added 103 ticket as a notice. i will document it in the nearest future

Alecs

[Andreas Nyholm]

I agree, this is the best way to go forward!

/Andreas

[Alexandru-Emil Lupu]

Hi!
Florian, could you commit your work? i am trying to use 1.4 branch in order to fix the install problems. but, for some reasons, i cannot, because "Fatal error: Class 'SfPeerBuilder' not found in " which is a symfony deprecation. I don't want to reinvent the wheel, so, i am waiting your commit to be able to start working ....

Alecs

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

[Florian]

Hello,

I'll try to commit what is done today!

[Sébastien HEITZMANN]

Hi,

i'm Florian's boss and I'm working on sfShop too.

Could you add me to the commiters please.

Thanks

Sébastien HEITZMANN
www.2le.net

Florian a écrit :

[Andreas Nyholm]

Hi.

Done. I've added this e-mail. Not sure if it will work or if you need a
google e-mail. Let me know if there are any problems.

Regards,
Andreas

S�bastien HEITZMANN wrote:
> Hi,
>
> i'm Florian's boss and I'm working on sfShop too.
>
> Could you add me to the commiters please.
>
> Thanks
>

> S�bastien HEITZMANN
> www.2le.net
>
> Florian a �crit :

>> Hello,
>>
>> I'll try to commit what is done today!
>>

>> Le 11/03/2010 18:36, Alexandru-Emil Lupu a �crit :

>>> <mailto:sfs...@googlegroups.com>.

>>> To unsubscribe from this group, send email to
>>> sfshop+un...@googlegroups.com

>>> <mailto:sfshop%2Bunsu...@googlegroups.com>.

[Alexandru-Emil Lupu]

Hi!
I cannot. I got my committer rights yesterday
However, you have to contact Andreas for that... and also to have a google account ..
Alecs

[Sébastien HEITZMANN]

It works.

Thanks.

Andreas Nyholm a �crit :

[Alexandru-Emil Lupu]

Ok!
nice one .. are you a doctrine or propel developer ? Do you have any things to commit on 1.4 branch ?
I just want to find out what has been done already and try to see what has to be done next, to evaluate the work needed in order to completely migrate to 1.4 ... and then to be able to sit back and try to make the installer like Sympal, to see what extra features we might add etc ...

And after a completely migration to the last version of Sf / propel, to be able to migrate to doctrine as well ...

After i will see what work has been already been done, i will start a new thread in order to be able to know who is working on what ... 

Alecs

On Fri, Mar 12, 2010 at 11:13 AM, Sébastien HEITZMANN <2...@2le.net> wrote:

It works.

Thanks.


Andreas Nyholm a écrit :

Hi.

Done. I've added this e-mail. Not sure if it will work or if you need a google e-mail. Let me know if there are any problems.

Regards,
Andreas

Sébastien HEITZMANN wrote:

Hi,

i'm Florian's boss and I'm working on sfShop too.

Could you add me to the commiters please.

Thanks

Sébastien HEITZMANN
www.2le.net

Florian a écrit :

Hello,

[Sébastien HEITZMANN]

I'm currently working on commiting my work.

For the moment it's sf 1.3. It's recommended to upgrade step by step.

We work on doctrine and propel but for my project we think it would be a to big work to migrate to doctrine. Maybe it could be a work for an other project.

I have some question about the project.

Actually all models and forms generated are not in the subversion. For our own project, we used to commit this files already. I think it's easyer to deploy. Can I commit this files ?

I would like to write some basic tests too. We use a Continious integration system ( hudson )which could run these test automatically.
I will commit these too.

Yours

Sébastien HEITZMANN


Alexandru-Emil Lupu a écrit :

[Andreas Nyholm]

Hi.

> We work on doctrine and propel but for my project we think it would be a
> to big work to migrate to doctrine. Maybe it could be a work for an
> other project.

If I ask this way: Would you mind using Doctrine if Alecs is doing the
migration? Just as a general question to see where we are going.

> Actually all models and forms generated are not in the subversion. For
> our own project, we used to commit this files already. I think it's
> easyer to deploy. Can I commit this files ?

Please do not commit classes generated with propel:build-XXXX. These
might be different for every commiter.

> I would like to write some basic tests too. We use a Continious
> integration system ( hudson )which could run these test automatically.
> I will commit these too.

No tests have been made this far. This is ok for me. Other opinions?

Regards,
Andreas

[Sébastien HEITZMANN]

Andreas Nyholm a �crit :

> Hi.
>
>> We work on doctrine and propel but for my project we think it would
>> be a to big work to migrate to doctrine. Maybe it could be a work for
>> an other project.
>
> If I ask this way: Would you mind using Doctrine if Alecs is doing the
> migration? Just as a general question to see where we are going.

Yes, Doctrine is a good product. The problem is that we need to deliver
our project within 6 week. So if this migration is done in 3/4 week we
are ok. We can help for some work on it but not all the migration.

>
>> Actually all models and forms generated are not in the subversion.
>> For our own project, we used to commit this files already. I think
>> it's easyer to deploy. Can I commit this files ?
>
> Please do not commit classes generated with propel:build-XXXX. These
> might be different for every commiter.
>

Ok, we will do that.

[Alexandru-Emil Lupu]

You can commit all what IS NOT:

cache/*
base/*
orm/*
base/*
log/*
data/sql/*
and so on...
the rest are safe to commit i think

after we get a sf 1.4 & propel stable version i want to port it as well on Doctrine... as i need to integrate with a Doctrine project. I could do it alone or helped ... i do not mind :)

Sebastien, i can help you with doctrine migration ... but i do not think we can do it in 4 weeks ... the sfshop thing is not my work project ... so it is done after hours ....

 Alecs

[Sébastien HEITZMANN]

And what about configuration files ?

Generally we do a propel.ini.sample in the svn and ignore the propel.ini
ou databases.yml

This is a security for not committing production password in a public
repository.

What do you think about that ?

Thanks.

S�bastien HEITZMANN a �crit :

[Alexandru-Emil Lupu]

Well ... for backwards compatibility i just created an user, a db and a pass like it is in the default sfshop project ...

you could commit those cfg files as well as long they don't contain your prod user / password

Also.. make sure that sfshop commit is not poluted with other project specific things ... (but you know better ).

Alecs

On Fri, Mar 12, 2010 at 12:05 PM, Sébastien HEITZMANN <2...@2le.net> wrote:

And what about configuration files ?

Generally we do a propel.ini.sample in the svn and ignore the propel.ini ou databases.yml

This is a security for not committing production password in a public repository.

What do you think about that ?

Thanks.

Sébastien HEITZMANN a écrit :

Andreas Nyholm a écrit :

Hi.

We work on doctrine and propel but for my project we think it would be a to big work to migrate to doctrine. Maybe it could be a work for an other project.

If I ask this way: Would you mind using Doctrine if Alecs is doing the migration? Just as a general question to see where we are going.

Yes, Doctrine is a good product. The problem is that we need to deliver our project within 6 week. So if this migration is done in 3/4 week we are ok. We can help for some work on it but not all the migration.

Actually all models and forms generated are not in the subversion. For our own project, we used to commit this files already. I think it's easyer to deploy. Can I commit this files ?

Please do not commit classes generated with propel:build-XXXX. These might be different for every commiter.

Ok, we will do that.

I would like to write some basic tests too. We use a Continious integration system ( hudson )which could run these test automatically.
I will commit these too.

No tests have been made this far. This is ok for me. Other opinions?

Regards,
Andreas

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

[Sébastien HEITZMANN]

Alexandru-Emil Lupu a écrit :

Well ... for backwards compatibility i just created an user, a db and a pass like it is in the default sfshop project ...

you could commit those cfg files as well as long they don't contain your prod user / password

Also.. make sure that sfshop commit is not poluted with other project specific things ... (but you know better ).

I think that I will use externals for all the plugins after I will be sure that all works out of the box. And it would be easy to commit sfshop updates.

For doctrine we will decide what to do after the 1.4 propel migration and see if we have the time to start a doctrine migration.

Yours

Is there some french in the mailing list ?

[Andreas Nyholm]

S�bastien HEITZMANN wrote:
> I think that I will use externals for all the plugins after I will be
> sure that all works out of the box. And it would be easy to commit
> sfshop updates.

I also do like this.

One change I would suggest you do if not already done is to change
symfony directory from lib/symfony to lib/vendor/symfony. This change
you can commit.

I have done so locally since I was having some problems with
"lib/symfony" and latest sf1.2.

/Andreas

[Alexandru-Emil Lupu]

Ok!
Starting from this point, after i got Andreas's consent i will be the an active development leader, so i will start to make some things, that i consider useful.
On management part:
- enable the wiki for freature request / proposals

I will start try to make some teams, in order to get sfShop translated in several languages, so, if is someone who is willing to help the  translation, i happy  :)

i know that i will provide Romanian translation for the project ... soon enough.


Andreas, i will do that small modification today ( lib/vendor/symfony ) , as i would add the romanian translations today ...

Alecs

[Sébastien HEITZMANN]

Ok, I've commit my version and change the symfony to /lib/vendor/

Andreas Nyholm a �crit :

[Sébastien HEITZMANN]

From my point of view I need to be able to manage multiple images for a product.

We will work on a more "user friendly" product management on backend.

We can also provide a french translation. But I'm wondering why the project use gettext and not xliff ? I have no preference but just wonder.

Thanks.

Alexandru-Emil Lupu a écrit :

[Alexandru-Emil Lupu]

Well ... i would think that is more appropriate to use the translations to the DB .. as the developer job is not a "editor" job...
but i don't mind to have it ...

Alecs

[Andreas Nyholm]

S�bastien HEITZMANN wrote:
> From my point of view I need to be able to manage multiple images for a
> product.

This is a good addition!

> We will work on a more "user friendly" product management on backend.

Excellent :)

Addition of new product option into product page would really be needed.

> We can also provide a french translation. But I'm wondering why the
> project use gettext and not xliff ? I have no preference but just wonder.

This have been from the beginning, don't know why. Other suggestions are
welcome.

/Andreas