Re: [oxid-dev-general] Blocks save path changed in 4.8?

[Alexander Kludt]

Well, currently I don't 
use any path in my metadata file:

'blocks' => array(
        array('template' => 
'order_overview.tpl', 'block'=>'admin_order_overview_export', 
'file'=>'admin_order_overview_export.tpl'),
    array('template' => 
'deliveryset_main.tpl', 'block'=>'admin_deliveryset_main_form', 
'file'=>'admin_deliveryset_main_form.tpl'),
    array('template' => 
'payment_main.tpl', 'block'=>'admin_payment_main_form', 
'file'=>'admin_payment_main_form.tpl'),
    array('template' => 
'form/user_checkout_change.tpl', 
'block'=>'user_checkout_shipping_change', 
'file'=>'user_checkout_shipping_change.tpl'),
    array('template' => 
'form/user_checkout_change.tpl', 
'block'=>'user_checkout_shipping_form',   
'file'=>'user_checkout_shipping_form.tpl'),
...

So I have to write it like this? Is this backwards compatible?

'blocks' => array(
        array('template' => 
'order_overview.tpl', 'block'=>'admin_order_overview_export', 
'file'=>'out/blocks/admin_order_overview_export.tpl'),
    array('template' => 
'deliveryset_main.tpl', 'block'=>'admin_deliveryset_main_form', 
'file'=>'out/blocks/ admin_deliveryset_main_form.tpl'),
    array('template' => 
'payment_main.tpl', 'block'=>'admin_payment_main_form', 'file'=>'out/blocks/
 admin_payment_main_form.tpl'),
    array('template' => 
'form/user_checkout_change.tpl', 
'block'=>'user_checkout_shipping_change', 'file'=>'out/blocks/ 
user_checkout_shipping_change.tpl'),
    array('template' => 
'form/user_checkout_change.tpl', 
'block'=>'user_checkout_shipping_form',   'file'=>'out/blocks/ 
user_checkout_shipping_form.tpl'),
        

-- mit
 freundlichen Grüßen
Alexander Kludt

__
Phone: 09283-5925453
Fax: 09283-592671
Skype: kingschnulli
Email: cod...@aggrosoft.de
Website: www.aggrosoft.de

__
Aggrosoft it intelligence GbR
Tannstrasse 12
95111 Rehau
GERMANY

Sitz Rehau, Amtsgericht Hof
Steuernummer: 223/165/54508
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773

___
Diese Nachricht ist nur für den Empfänger bestimmt, sollten
Sie nicht der Empfänger sein löschen Sie diese Nachricht
umgehend und geben Sie uns bitte per Email (cod...@aggrosoft.de)
 Bescheid
über den fälschlichen Erhalt. 
  





   	   
   	Marat Bedoev  
  Dienstag, 21. 
Januar 2014 14:57
  






Check
 if the patch in the oxtplblocks table is correct, cause once the blocks
 are copied into the database, they will not be updated
 if metadata changes
 


Von:
 dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org]
Im Auftrag von Alexander Kludt
Gesendet: Dienstag, 21. Januar 2014 14:51
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Blocks save path changed in 4.8?


 
Hi,

thanks for your reply - but if I just keep the old structure it won't 
enter the blocks into oxtplblocks.
I moved them, reactivated the module - now he writes them to the table 
but still won't show them.

-- 
mit freundlichen Grüßen 
Alexander Kludt 

__ 
Phone: 09283-5925453 
Fax: 09283-592671 
Skype: kingschnulli 
Email: cod...@aggrosoft.de
 
Website: www.aggrosoft.de
 

__ 
Aggrosoft it intelligence GbR 
Tannstrasse 12 
95111 Rehau 
GERMANY 

Sitz Rehau, Amtsgericht Hof 
Steuernummer: 223/165/54508 
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773 

___ 
Diese Nachricht ist nur für den Empfänger bestimmt, sollten 
Sie nicht der Empfänger sein löschen Sie diese Nachricht 
umgehend und geben Sie uns bitte per Email (cod...@aggrosoft.de) Bescheid

über den fälschlichen Erhalt.  







___dev-general 
mailing listdev-general@lists.oxidforge.orghttp://dir.gmane.org/gmane.comp.php.oxid.general
   	   
   	Alexander Kludt  
  Dienstag, 21. 
Januar 2014 14:51
  

Hi,

thanks for your reply - but if I just keep the old structure it won't 
enter the blocks into oxtplblocks.
I moved them, reactivated the module - now he writes them to the table 
but still won't show them.




___dev-general 
mailing listdev-general@lists.oxidforge.orghttp://dir.gmane.org/gmane.comp.php.oxid.general
   	   
   	Frank Zunderer  
  Dienstag, 21. 
Januar 2014 14:41
  Hi, i think it wasn’t changed, it’s still out/blocks if you 
specify only the filename, but it can be any folder if you specify with 
path from module folder. Regards,Frank Zunderer Von:
 dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Alexander
 KludtGesendet: Dienstag, 21. Januar 2014 14:33An:
 dev-general@lists.oxidforge.orgBetreff: [oxid-dev-general] 
Blocks save path changed in 4.8? Hi guys,from
 what I can see the blocks in 4.8 are now stored in modules/mymodule/views/blocksthey
 used to be stored in modules/mymodules/out/blockswhy
 the heck was that changed without any backward comp

Re: [oxid-dev-general] Blocks save path changed in 4.8?

[Marat Bedoev]

Check if the patch in the oxtplblocks table is correct, cause once the blocks 
are copied into the database, they will not be updated if metadata changes

Von: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Alexander Kludt
Gesendet: Dienstag, 21. Januar 2014 14:51
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Blocks save path changed in 4.8?

Hi,

thanks for your reply - but if I just keep the old structure it won't enter the 
blocks into oxtplblocks.
I moved them, reactivated the module - now he writes them to the table but 
still won't show them.
--
mit freundlichen Grüßen
Alexander Kludt

__
Phone: 09283-5925453
Fax: 09283-592671
Skype: kingschnulli
Email: cod...@aggrosoft.de
Website: www.aggrosoft.de

__
Aggrosoft it intelligence GbR
Tannstrasse 12
95111 Rehau
GERMANY

Sitz Rehau, Amtsgericht Hof
Steuernummer: 223/165/54508
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773

___
Diese Nachricht ist nur für den Empfänger bestimmt, sollten
Sie nicht der Empfänger sein löschen Sie diese Nachricht
umgehend und geben Sie uns bitte per Email 
(cod...@aggrosoft.de) Bescheid
über den fälschlichen Erhalt.



[cid:image001.jpg@01CF16B9.2B1B6450]
Frank Zunderer
Dienstag, 21. Januar 2014 14:41
Hi,

i think it wasn't changed, it's still out/blocks if you specify only the 
filename, but it can be any folder if you specify with path from module folder.

Regards,
Frank Zunderer

Von: 
dev-general-boun...@lists.oxidforge.org
 [mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Alexander Kludt
Gesendet: Dienstag, 21. Januar 2014 14:33
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] Blocks save path changed in 4.8?

Hi guys,

from what I can see the blocks in 4.8 are now stored in

modules/mymodule/views/blocks

they used to be stored in

modules/mymodules/out/blocks

why the heck was that changed without any backward compatibility?
Was this mentioned anywhere? Did I miss anything?

--
best regards
Alexander Kludt

__
Phone: 09283-5925453
Fax: 09283-592671
Skype: kingschnulli
Email: cod...@aggrosoft.de
Website: www.aggrosoft.de

__
Aggrosoft it intelligence GbR
Tannstrasse 12
95111 Rehau
GERMANY

Sitz Rehau, Amtsgericht Hof
Steuernummer: 223/165/54508
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773

___
Diese Nachricht ist nur für den Empfänger bestimmt, sollten
Sie nicht der Empfänger sein löschen Sie diese Nachricht
umgehend und geben Sie uns bitte per Email 
(cod...@aggrosoft.de) Bescheid
über den fälschlichen Erhalt.
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
[cid:image002.jpg@01CF16B9.2B1B6450]
Alexander Kludt
Dienstag, 21. Januar 2014 14:32
Hi guys,

from what I can see the blocks in 4.8 are now stored in

modules/mymodule/views/blocks

they used to be stored in

modules/mymodules/out/blocks

why the heck was that changed without any backward compatibility?
Was this mentioned anywhere? Did I miss anything?

--
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
<><>___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Blocks save path changed in 4.8?

[Alexander Kludt]

Hi,

thanks for your reply - but if I just keep the old structure it won't 
enter the blocks into oxtplblocks.
I moved them, reactivated the module - now he writes them to the table 
but still won't show them.
-- mit
 freundlichen Grüßen
Alexander Kludt

__
Phone: 09283-5925453
Fax: 09283-592671
Skype: kingschnulli
Email: cod...@aggrosoft.de
Website: www.aggrosoft.de

__
Aggrosoft it intelligence GbR
Tannstrasse 12
95111 Rehau
GERMANY

Sitz Rehau, Amtsgericht Hof
Steuernummer: 223/165/54508
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773

___
Diese Nachricht ist nur für den Empfänger bestimmt, sollten
Sie nicht der Empfänger sein löschen Sie diese Nachricht
umgehend und geben Sie uns bitte per Email (cod...@aggrosoft.de)
 Bescheid
über den fälschlichen Erhalt. 
  





   	   
   	Frank Zunderer  
  Dienstag, 21. 
Januar 2014 14:41
  Hi, i think it wasn’t changed, it’s still out/blocks if you 
specify only the filename, but it can be any folder if you specify with 
path from module folder. Regards,Frank Zunderer Von:
 dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Alexander
 KludtGesendet: Dienstag, 21. Januar 2014 14:33An:
 dev-general@lists.oxidforge.orgBetreff: [oxid-dev-general] 
Blocks save path changed in 4.8? Hi guys,from
 what I can see the blocks in 4.8 are now stored in modules/mymodule/views/blocksthey
 used to be stored in modules/mymodules/out/blockswhy
 the heck was that changed without any backward compatibility?Was 
this mentioned anywhere? Did I miss anything?-- best regardsAlexander
 Kludt __ Phone: 09283-5925453 Fax:
 09283-592671 Skype: kingschnulli Email: cod...@aggrosoft.de
 Website: www.aggrosoft.de
 __ Aggrosoft it intelligence GbR Tannstrasse
 12 95111 Rehau GERMANY Sitz Rehau, Amtsgericht Hof Steuernummer:
 223/165/54508 Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: 
DE260722773 ___ Diese Nachricht ist 
nur für den Empfänger bestimmt, sollten Sie nicht der Empfänger sein
 löschen Sie diese Nachricht umgehend und geben Sie uns bitte per 
Email (cod...@aggrosoft.de)
 Bescheid über den fälschlichen Erhalt.  ___dev-general
 mailing listdev-general@lists.oxidforge.orghttp://dir.gmane.org/gmane.comp.php.oxid.general
   	   
   	Alexander Kludt  
  Dienstag, 21. 
Januar 2014 14:32
  

Hi guys,
  
from what I can see the blocks in 4.8 are now stored in 
  
modules/mymodule/views/blocks
  
they used to be stored in 
  
modules/mymodules/out/blocks
  
why the heck was that changed without any backward compatibility?
Was this mentioned anywhere? Did I miss anything?
  
-- 
  
___dev-general 
mailing listdev-general@lists.oxidforge.orghttp://dir.gmane.org/gmane.comp.php.oxid.general


___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Pros and cons for module-connectors

[Marco Steinhaeuser]

Hi everybody,

glad to see this valuable discussion coming up and just talked to Ina (Head of 
Development) about it. She asked me to reply on behalf of herself.

> yes, some type of dependency management is a must for the OXID module system!

This is exactly what we have in mind - just didn't make a proof of concept for 
it yet.
With OXID eShop version 4.8/5.1 we introduced "oxonlinemoduleversionnotifier" 
amongst some new core classes, as well as an online license check. These 
functionality shall be improved further in a manner that module versions and 
shop versions can be checked as well as the dependencies for it etc.

As I said, we are still in a phase of thinking about the entire concept and am 
happy about discussions on it. Also we'd appreciate if somebody would like to 
contribute something like a spike solution, a prototype or some written concept.

Cheers!
Marco


From: dev-general-boun...@lists.oxidforge.org 
[dev-general-boun...@lists.oxidforge.org] on behalf of Stefan Moises 
[moi...@shoptimax.de]
Sent: Tuesday, January 21, 2014 11:42 AM
To: dev-general@lists.oxidforge.org
Subject: Re: [oxid-dev-general] Pros and cons for module-connectors

Hi,

yes, some type of dependency management is a must for the OXID module system!

As a workaround, we have started a simple module managing dependencies 
("smx_module_deps"), at the moment you can only add other module ids which your 
module depends on, e.g. in metadata.php you can add:

'depends' => array(
'smx_filialabholung'
),
'settings' => array(),

On our todo list are some more features like adding versions, e.g. like so

'depends' => array(
array('id' => 'smx_filialabholung', 'version' => '1.1'),
),
'settings' => array(),

What it does at the moment is simply to make sure that a module can't be 
manually disabled if other modules depend on it. We have to extend that so that 
the shop also doesn't automatically disable modules if metadata.php has new 
"extend" entries etc.

But ideally, this should really be part of the OXID core

cheers,
Stefan

Am 21.01.2014 09:38, schrieb Joscha Krug | marmalade GmbH:
Hi,

same for me: I also don't like them. If you have dependencies between modules 
go for composer or something the like.

Best would be if OXID could come up with an extension in the metadata.php in 
which you could tell "this module is based on that other module".

Best regards

Joscha


//-

Joscha Krug
marmalade GmbH

www.marmalade.de
k...@marmalade.de

Leibnizstr.25
39104 Magdeburg
GERMANY

phone: +49 (0) 391 / 559 22 104
fax:  +49 (0) 391 / 559 22 106

OXMOB | mobile 
Template
Das einfach geniale OXID eShop Modul.
Ab sofort in unserem 
Online-Shop
 erhältlich.

Am 21.01.2014 08:44, schrieb Marcel Müller:
Hey!

I don’t like such additional connector modules. They have their own bugs and 
generating system-wide errors, mostly. Especially when the module has an own 
style and/or database tables far from oxid. I had scenarios within a customer 
tried to remove a connectors modul and gets a lot of trouble with the system. 
But if you want to get rich with support, this could be a model ;)

What about a wrapper script inside every module or inside the vendor structure? 
With that you can also check the versions and be agile.


Mit freundlichen Grüßen

Marcel Müller
Webentwicklung / Projektmanagement
eMail: m...@aikme.de

[http://static.aikme.de/mail/sig.jpg]

aikme GmbH
Rheinstraße 43-45
55116 Mainz / Deutschland
Telefon: 06131 92 06 503
Telefax: 06131 92 08 334
www.aikme.de


aikme GmbH
Geschäftsführer: Sascha Coldewey
Sitz in Mainz, Registergericht: Mainz
Registernummer: HRB 44835
Umsatzsteuer ID: DE282561622

Am Dienstag, 21. Januar 2014 um 08:31 schrieb Roman Allenstein:

Hi folks,

me and my team are developing a concept for us, how to develop modules
for oxid. We are now at the point where we have to decide to develope a
connector-module for all our coming modules or not.

We know that some agecies use their own connector to integrate their
modules in oxid. And i am pretty unsure if this is the way to go because
oxid provides a standardized way to integrate modules.

Whats your pros and cons for using an own connector?

Greets
Roman
--
Dipl.Winf. (FH) Roman Allenstein
Sales Manager E-Commerce
Spark 5 GmbH
Lutherstraße 7
27570 Bremerhaven

Fon: +49-471-4836-3547
Fax: +49-6151-8508-111

Mail: roman.allenst...@spark5.de
Web: http://www.spark5.de
--

Geschäftsführer:
Dipl. Designer Till Middelhauve
Dipl. Informatiker Witold Wegner
Amtsgericht Darmstadt, HRB 7809

Diese E-Mail könnte vertrauliche 

Re: [oxid-dev-general] Blocks save path changed in 4.8?

[Frank Zunderer]

Hi,

 

i think it wasn’t changed, it’s still out/blocks if you specify only the
filename, but it can be any folder if you specify with path from module
folder.

 

Regards,

Frank Zunderer

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Alexander
Kludt
Gesendet: Dienstag, 21. Januar 2014 14:33
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] Blocks save path changed in 4.8?

 

Hi guys,

from what I can see the blocks in 4.8 are now stored in 

modules/mymodule/views/blocks

they used to be stored in 

modules/mymodules/out/blocks

why the heck was that changed without any backward compatibility?
Was this mentioned anywhere? Did I miss anything?

-- 

best regards
Alexander Kludt 

__ 
Phone: 09283-5925453 
Fax: 09283-592671 
Skype: kingschnulli 
Email: cod...@aggrosoft.de 
Website: www.aggrosoft.de 

__ 
Aggrosoft it intelligence GbR 
Tannstrasse 12 
95111 Rehau 
GERMANY 

Sitz Rehau, Amtsgericht Hof 
Steuernummer: 223/165/54508 
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773 

___ 
Diese Nachricht ist nur für den Empfänger bestimmt, sollten 
Sie nicht der Empfänger sein löschen Sie diese Nachricht 
umgehend und geben Sie uns bitte per Email (cod...@aggrosoft.de) Bescheid 
über den fälschlichen Erhalt.  

___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Blocks save path changed in 4.8?

[Marat Bedoev]

Hello,

in oxUtilsView->_getTemplateBlock()  (row 458) you can see, where OXID is 
looking for block templates.
In general you can place your block where ever you want but you need an 
absolute path to it in your metadata.php
If you do only have file's basename in your metadata.php, OXID will be looking 
for blocks in module/your-module/out/blocks/


greetings.
Marat

Von: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Alexander Kludt
Gesendet: Dienstag, 21. Januar 2014 14:33
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] Blocks save path changed in 4.8?

Hi guys,

from what I can see the blocks in 4.8 are now stored in

modules/mymodule/views/blocks

they used to be stored in

modules/mymodules/out/blocks

why the heck was that changed without any backward compatibility?
Was this mentioned anywhere? Did I miss anything?

--
best regards
Alexander Kludt

__
Phone: 09283-5925453
Fax: 09283-592671
Skype: kingschnulli
Email: cod...@aggrosoft.de
Website: www.aggrosoft.de

__
Aggrosoft it intelligence GbR
Tannstrasse 12
95111 Rehau
GERMANY

Sitz Rehau, Amtsgericht Hof
Steuernummer: 223/165/54508
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773

___
Diese Nachricht ist nur für den Empfänger bestimmt, sollten
Sie nicht der Empfänger sein löschen Sie diese Nachricht
umgehend und geben Sie uns bitte per Email 
(cod...@aggrosoft.de) Bescheid
über den fälschlichen Erhalt.
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

[oxid-dev-general] Blocks save path changed in 4.8?

[Alexander Kludt]

Hi guys,

from what I can see the blocks in 4.8 are now stored in

modules/mymodule/views/blocks

they used to be stored in

modules/mymodules/out/blocks

why the heck was that changed without any backward compatibility?
Was this mentioned anywhere? Did I miss anything?

--
best regards
Alexander Kludt

__
Phone: 09283-5925453
Fax: 09283-592671
Skype: kingschnulli
Email: cod...@aggrosoft.de
Website: www.aggrosoft.de

__
Aggrosoft it intelligence GbR
Tannstrasse 12
95111 Rehau
GERMANY

Sitz Rehau, Amtsgericht Hof
Steuernummer: 223/165/54508
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773

___
Diese Nachricht ist nur für den Empfänger bestimmt, sollten
Sie nicht der Empfänger sein löschen Sie diese Nachricht
umgehend und geben Sie uns bitte per Email (cod...@aggrosoft.de) Bescheid
über den fälschlichen Erhalt.

___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Pros and cons for module-connectors

[Frank Zunderer]

Hello,

 

one problem with those connectors is that they add value for the developer,
but not so much for the customer. This may be the reason why no one likes
those connectors, except the developers their own ;-). The more
sophisticated they are, the more they add errors and do not give the
impression of a unified experience when installing modules.

 

Dependencies in general may be a problem but not so much I think. As it is,
it seems connectors introduce more dependencies because every module depends
on the existence of the correct version of the corresponding connector.

 

What I would really appreciate is a module installer/updater/uninstaller
(that does not contain any module functionality, so it wouldn’t be required
for the modules to work) on github, until this functionality is built into
the core.

 

Regards,

Frank Zunderer

 

 

 

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Stefan
Moises
Gesendet: Dienstag, 21. Januar 2014 11:42
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Pros and cons for module-connectors

 

Hi,

yes, some type of dependency management is a must for the OXID module
system!

As a workaround, we have started a simple module managing dependencies
("smx_module_deps"), at the moment you can only add other module ids which
your module depends on, e.g. in metadata.php you can add:

'depends' => array(
'smx_filialabholung'
),
'settings' => array(),

On our todo list are some more features like adding versions, e.g. like so

'depends' => array(
array('id' => 'smx_filialabholung', 'version' => '1.1'),
),
'settings' => array(),

What it does at the moment is simply to make sure that a module can't be
manually disabled if other modules depend on it. We have to extend that so
that the shop also doesn't automatically disable modules if metadata.php has
new "extend" entries etc.

But ideally, this should really be part of the OXID core

cheers,
Stefan

Am 21.01.2014 09:38, schrieb Joscha Krug | marmalade GmbH:

Hi,

same for me: I also don't like them. If you have dependencies between
modules go for composer or something the like.

Best would be if OXID could come up with an extension in the metadata.php in
which you could tell "this module is based on that other module".

Best regards

Joscha


//-

 
Joscha Krug
marmalade GmbH

 

www.marmalade.de  
k...@marmalade.de

 

Leibnizstr.25
39104 Magdeburg
GERMANY

 

phone: +49 (0) 391 / 559 22 104
fax:  +49 (0) 391 / 559 22 106

OXMOB | mobile Template
 
Das einfach geniale OXID eShop Modul.
Ab sofort in unserem Online-Shop
  erhältlich.

Am 21.01.2014 08:44, schrieb Marcel Müller:

Hey! 

 

I don’t like such additional connector modules. They have their own bugs and
generating system-wide errors, mostly. Especially when the module has an own
style and/or database tables far from oxid. I had scenarios within a
customer tried to remove a connectors modul and gets a lot of trouble with
the system. But if you want to get rich with support, this could be a model
;)

 

What about a wrapper script inside every module or inside the vendor
structure? With that you can also check the versions and be agile.

 

Mit freundlichen Grüßen

Marcel Müller
Webentwicklung / Projektmanagement
eMail: m...@aikme.de

  Das Bild wurde vom Absender entfernt.


aikme GmbH
Rheinstraße 43-45
55116 Mainz / Deutschland
Telefon: 06131 92 06 503
Telefax: 06131 92 08 334
www.aikme.de  

 

aikme GmbH 
Geschäftsführer: Sascha Coldewey 
Sitz in Mainz, Registergericht: Mainz 
Registernummer: HRB 44835 
Umsatzsteuer ID: DE282561622 

Am Dienstag, 21. Januar 2014 um 08:31 schrieb Roman Allenstein:

Hi folks,

 

me and my team are developing a concept for us, how to develop modules 

for oxid. We are now at the point where we have to decide to develope a 

connector-module for all our coming modules or not.

 

We know that some agecies use their own connector to integrate their 

modules in oxid. And i am pretty unsure if this is the way to go because 

oxid provides a standardized way to integrate modules.

 

Whats your pros and cons for using an own connector?

 

Greets

Roman

-- 

Dipl.Winf. (FH) Roman Allenstein

Sales Manager E-Commerce

Spark 5 GmbH

Lutherstraße 7

27570 Bremerhaven

 

Fon: +49-471-4836-3547

Fax: +49-6151-8508-111

 

Mail: roman.allenst...@spark5.de

Web: http://www.spark5.de

--

 

Geschäftsführer:

Dipl. Designer Till Middelhauve

Dipl. Informatiker Witold Wegner

Amtsgericht Darmstadt, HRB 7809

 

Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte 

Informationen enthalten. Wenn Sie nicht der ri

Re: [oxid-dev-general] Pros and cons for module-connectors

[Stefan Moises]

Hi,

yes, some type of dependency management is a must for the OXID module 
system!


As a workaround, we have started a simple module managing dependencies 
("smx_module_deps"), at the moment you can only add other module ids 
which your module depends on, e.g. in metadata.php you can add:


*'depends' => array(**
**'smx_filialabholung'**
**),*
'settings' => array(),

On our todo list are some more features like adding versions, e.g. like so

'depends' => array(
array('id' => 'smx_filialabholung', 'version' => '1.1'),
),
'settings' => array(),

What it does at the moment is simply to make sure that a module can't be 
manually disabled if other modules depend on it. We have to extend that 
so that the shop also doesn't automatically disable modules if 
metadata.php has new "extend" entries etc.


But ideally, this should really be part of the OXID core

cheers,
Stefan

Am 21.01.2014 09:38, schrieb Joscha Krug | marmalade GmbH:

Hi,

same for me: I also don't like them. If you have dependencies between 
modules go for composer or something the like.


Best would be if OXID could come up with an extension in the 
metadata.php in which you could tell "this module is based on that 
other module".


Best regards

Joscha


//-

Joscha Krug
marmalade GmbH
www.marmalade.de 
k...@marmalade.de 
Leibnizstr.25
39104 Magdeburg
GERMANY
phone: +49 (0) 391 / 559 22 104
fax:  +49 (0) 391 / 559 22 106

*OXMOB | mobile Template 
*

Das einfach geniale OXID eShop Modul.
Ab sofort in unserem Online-Shop 
 
erhältlich.


Am 21.01.2014 08:44, schrieb Marcel Müller:

Hey!

I don't like such additional connector modules. They have their own 
bugs and generating system-wide errors, mostly. Especially when the 
module has an own style and/or database tables far from oxid. I had 
scenarios within a customer tried to remove a connectors modul and 
gets a lot of trouble with the system. But if you want to get rich 
with support, this could be a model ;)


What about a wrapper script inside every module or inside the vendor 
structure? With that you can also check the versions and be agile.


*Mit freundlichen Grüßen*

Marcel Müller
Webentwicklung / Projektmanagement
eMail: m...@aikme.de 



aikme GmbH
Rheinstraße 43-45
55116 Mainz / Deutschland
Telefon: 06131 92 06 503
Telefax: 06131 92 08 334
www.aikme.de 

aikme GmbH
Geschäftsführer: Sascha Coldewey
Sitz in Mainz, Registergericht: Mainz
Registernummer: HRB 44835
Umsatzsteuer ID: DE282561622

Am Dienstag, 21. Januar 2014 um 08:31 schrieb Roman Allenstein:


Hi folks,

me and my team are developing a concept for us, how to develop modules
for oxid. We are now at the point where we have to decide to develope a
connector-module for all our coming modules or not.

We know that some agecies use their own connector to integrate their
modules in oxid. And i am pretty unsure if this is the way to go 
because

oxid provides a standardized way to integrate modules.

Whats your pros and cons for using an own connector?

Greets
Roman
--
Dipl.Winf. (FH) Roman Allenstein
Sales Manager E-Commerce
Spark 5 GmbH
Lutherstraße 7
27570 Bremerhaven

Fon: +49-471-4836-3547
Fax: +49-6151-8508-111

Mail: roman.allenst...@spark5.de 
Web: http://www.spark5.de
--

Geschäftsführer:
Dipl. Designer Till Middelhauve
Dipl. Informatiker Witold Wegner
Amtsgericht Darmstadt, HRB 7809

Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort 
den

Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. 
Any
unauthorised copying, disclosure or distribution of the material in 
this

e-mail is strictly forbidden.
___
dev-general mailing list
dev-general@lists.oxidforge.org 
http://dir.gmane.org/gmane.comp.php.oxid.general




___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general




___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general


--
Mit den besten Grüßen aus Nürnberg,
Stefan Moises

**

Re: [oxid-dev-general] Pros and cons for module-connectors

[Markus Zok]

Hi Roman,

I can provide you with our own "module connector" though we like to call 
it framework. Don't let the name fool you, its basically a lightweight 
class that does what OXID can't: Bring streamlined OOP to modules.


In our view the metadata files are really a bad design decision. The 
syntax is volatile: you always have to check twice, if you need realtive 
or absolute paths, whether to include extensions or not, and top of 
that: some "files" need to be in special directories, like the blocks.


So we have a Module class. You simply inherit from it, modify the 
required properties and are ready to start with the logic. The Module 
class introduces lots of helper methodes for working with the database, 
the config and module files / paths.


The only requirement for inclusion in shops is to install the framework 
first. By the way, the framework is not encrypted and does not derive 
any classes from OXID. So it is a real standalone module without 
version-critical dependencies.


Mit besten Wünschen,
Markus Zok
*Markus Zok*
Heckenstr. 4
40764 Langenfeld
Deutschland Tel:
Mobil:
E-Mail: +49 (0) 2173 - 848 225
+49 (0) 177 - 404 89 65
mar...@zoks.net Internet:   www.zoks.net 

Am 21.01.14 08:31, schrieb Roman Allenstein:

Hi folks,

me and my team are developing a concept for us, how to develop modules 
for oxid. We are now at the point where we have to decide to develope 
a connector-module for all our coming modules or not.


We know that some agecies use their own connector to integrate their 
modules in oxid. And i am pretty unsure if this is the way to go 
because oxid provides a standardized way to integrate modules.


Whats your pros and cons for using an own connector?

Greets
Roman


___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Pros and cons for module-connectors

[Tobias Merkl]

but what are these reusable extensions?

oxid is on the may, makeing shop core slender. so atm it´s very hard to
put new code into :-(

the most used „helper module“ is clear temp. there is an good extension
from oxid cookbook,
or „moduledebug“ or „devmodules“ from oxid core developers.
another good helper module would be a logger.

perhaps we can make here an collection of modules which we need or use and
post it to
oxidforge wiki?

regards

tobias


-Ursprüngliche Nachricht-
Von: Roman Allenstein 
Organisation: Spark 5
Antworten an: "dev-general@lists.oxidforge.org"

Datum: Dienstag, 21. Januar 2014 09:50
An: "dev-general@lists.oxidforge.org" 
Betreff: Re: [oxid-dev-general] Pros and cons for module-connectors

I really don't like the use of an connector but some of my team-member
argument that it's good to put all reusable extensions in one
connector-module instead of putting them in every module, that we are
developing.
My argument against a connector is the problem with the dependencies
while an upgrade-process of the connector.

@Joscha
the use of composer is a really great idea. Have you allready used
composer for a module?

@OXID
I agree to Joscha, that we need a dependency-setting (including version)
for modules.

Greets
Roman

 > Am 21.01.2014 09:40, schrieb Tobias Merkl:
> roman, what´s your reason why you would use/create an own connector?
>
> Von: Joscha Krug | marmalade GmbH  Hi,
> same for me: I also don't like them. If you have dependencies between
> modules go for composer or something the like.
> Best would be if OXID could come up with an extension in the
> metadata.php in which you could tell "this module is based on that other
> module".
>
> Best regards
>
> Joscha
> Am 21.01.2014 08:44, schrieb Marcel Müller:
>> Hey!
>>
>> I don’t like such additional connector modules. They have their own
>> bugs and generating system-wide errors, mostly. Especially when the
>> module has an own style and/or database tables far from oxid. I had
>> scenarios within a customer tried to remove a connectors modul and
>> gets a lot of trouble with the system. But if you want to get rich
>> with support, this could be a model ;)
>>
>> What about a wrapper script inside every module or inside the vendor
>> structure? With that you can also check the versions and be agile.
>>
>> *Mit freundlichen Grüßen*
>>
>> Marcel Müller
>>
>> Am Dienstag, 21. Januar 2014 um 08:31 schrieb Roman Allenstein:
>>
>>> Hi folks,
>>>
>>> me and my team are developing a concept for us, how to develop modules
>>> for oxid. We are now at the point where we have to decide to develope a
>>> connector-module for all our coming modules or not.
>>>
>>> We know that some agecies use their own connector to integrate their
>>> modules in oxid. And i am pretty unsure if this is the way to go
>>>because
>>> oxid provides a standardized way to integrate modules.
>>>
>>> Whats your pros and cons for using an own connector?
>>>
>>> Greets
>>> Roman
>>> --
>>> Dipl.Winf. (FH) Roman Allenstein
>>> Sales Manager E-Commerce
>>> Spark 5 GmbH
>>> Lutherstraße 7
>>> 27570 Bremerhaven
>>>
>>> Fon: +49-471-4836-3547
>>> Fax: +49-6151-8508-111
>>>
>>> Mail: roman.allenst...@spark5.de 
>>> Web: http://www.spark5.de
>>> --
>>>
>>> Geschäftsführer:
>>> Dipl. Designer Till Middelhauve
>>> Dipl. Informatiker Witold Wegner
>>> Amtsgericht Darmstadt, HRB 7809
>>>
>>> Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte
>>> Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder
>>> diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort
>>>den
>>> Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
>>> die unbefugte Weitergabe dieser Mail sind nicht gestattet.
>>>
>>> This e-mail may contain confidential and/or privileged information. If
>>> you are not the intended recipient (or have received this e-mail in
>>> error) please notify the sender immediately and destroy this e-mail.
>>>Any
>>> unauthorised copying, disclosure or distribution of the material in
>>>this
>>> e-mail is strictly forbidden.
>>> ___
>>> dev-general mailing list
>>> dev-general@lists.oxidforge.org
>>>
>>> http://dir.gmane.org/gmane.comp.php.oxid.general
>>
>>
>>
>> ___
>> dev-general mailing list
>> 
>>dev-general@lists.oxidforge.orghttp://dir.gmane.org/gmane.comp.php.oxid.g
>>eneral
>
>
>
> ___
> dev-general mailing list
> dev-general@lists.oxidforge.org
> http://dir.gmane.org/gmane.comp.php.oxid.general
>


-- 
Dipl.Winf. (FH) Roman Allenstein
Sales Manager E-Commerce
Spark 5 GmbH
Lutherstraße 7
27570 Bremerhaven

Fon: +49-471-4836-3547
Fax: +49-6151-8508-111

Mail: roman.allenst...@spark5.de
Web: http://www.spark5.de
--

Geschäftsführer:
Dipl. Designer Till Middelhauve
Dipl. Informatiker Witold Wegner
Amtsgericht Darms

Re: [oxid-dev-general] Pros and cons for module-connectors

[Roman Allenstein]

I really don't like the use of an connector but some of my team-member 
argument that it's good to put all reusable extensions in one 
connector-module instead of putting them in every module, that we are 
developing.
My argument against a connector is the problem with the dependencies 
while an upgrade-process of the connector.


@Joscha
the use of composer is a really great idea. Have you allready used 
composer for a module?


@OXID
I agree to Joscha, that we need a dependency-setting (including version) 
for modules.


Greets
Roman

> Am 21.01.2014 09:40, schrieb Tobias Merkl:

roman, what´s your reason why you would use/create an own connector?

Von: Joscha Krug | marmalade GmbH 
Hey!

I don’t like such additional connector modules. They have their own
bugs and generating system-wide errors, mostly. Especially when the
module has an own style and/or database tables far from oxid. I had
scenarios within a customer tried to remove a connectors modul and
gets a lot of trouble with the system. But if you want to get rich
with support, this could be a model ;)

What about a wrapper script inside every module or inside the vendor
structure? With that you can also check the versions and be agile.

*Mit freundlichen Grüßen*

Marcel Müller

Am Dienstag, 21. Januar 2014 um 08:31 schrieb Roman Allenstein:


Hi folks,

me and my team are developing a concept for us, how to develop modules
for oxid. We are now at the point where we have to decide to develope a
connector-module for all our coming modules or not.

We know that some agecies use their own connector to integrate their
modules in oxid. And i am pretty unsure if this is the way to go because
oxid provides a standardized way to integrate modules.

Whats your pros and cons for using an own connector?

Greets
Roman
--
Dipl.Winf. (FH) Roman Allenstein
Sales Manager E-Commerce
Spark 5 GmbH
Lutherstraße 7
27570 Bremerhaven

Fon: +49-471-4836-3547
Fax: +49-6151-8508-111

Mail: roman.allenst...@spark5.de 
Web: http://www.spark5.de
--

Geschäftsführer:
Dipl. Designer Till Middelhauve
Dipl. Informatiker Witold Wegner
Amtsgericht Darmstadt, HRB 7809

Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
___
dev-general mailing list
dev-general@lists.oxidforge.org 
http://dir.gmane.org/gmane.comp.php.oxid.general




___
dev-general mailing list
dev-general@lists.oxidforge.orghttp://dir.gmane.org/gmane.comp.php.oxid.general




___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general




--
Dipl.Winf. (FH) Roman Allenstein
Sales Manager E-Commerce
Spark 5 GmbH
Lutherstraße 7
27570 Bremerhaven

Fon: +49-471-4836-3547
Fax: +49-6151-8508-111

Mail: roman.allenst...@spark5.de
Web: http://www.spark5.de
--

Geschäftsführer:
Dipl. Designer Till Middelhauve
Dipl. Informatiker Witold Wegner
Amtsgericht Darmstadt, HRB 7809

Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte 
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder 
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den 
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie 
die unbefugte Weitergabe dieser Mail sind nicht gestattet.


This e-mail may contain confidential and/or privileged information. If 
you are not the intended recipient (or have received this e-mail in 
error) please notify the sender immediately and destroy this e-mail. Any 
unauthorised copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.

___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Pros and cons for module-connectors

[Tobias Merkl]

roman, what´s your reason why you would use/create an own connector?

Von: Joscha Krug | marmalade GmbH mailto:k...@marmalade.de>>
Antworten an: 
"dev-general@lists.oxidforge.org" 
mailto:dev-general@lists.oxidforge.org>>
Datum: Dienstag, 21. Januar 2014 09:38
An: "dev-general@lists.oxidforge.org" 
mailto:dev-general@lists.oxidforge.org>>
Betreff: Re: [oxid-dev-general] Pros and cons for module-connectors

Hi,

same for me: I also don't like them. If you have dependencies between modules 
go for composer or something the like.

Best would be if OXID could come up with an extension in the metadata.php in 
which you could tell "this module is based on that other module".

Best regards

Joscha


//-

Joscha Krug
marmalade GmbH

www.marmalade.de
k...@marmalade.de

Leibnizstr.25
39104 Magdeburg
GERMANY

phone: +49 (0) 391 / 559 22 104
fax:  +49 (0) 391 / 559 22 106

OXMOB | mobile 
Template
Das einfach geniale OXID eShop Modul.
Ab sofort in unserem 
Online-Shop
 erhältlich.

Am 21.01.2014 08:44, schrieb Marcel Müller:
Hey!

I don’t like such additional connector modules. They have their own bugs and 
generating system-wide errors, mostly. Especially when the module has an own 
style and/or database tables far from oxid. I had scenarios within a customer 
tried to remove a connectors modul and gets a lot of trouble with the system. 
But if you want to get rich with support, this could be a model ;)

What about a wrapper script inside every module or inside the vendor structure? 
With that you can also check the versions and be agile.


Mit freundlichen Grüßen

Marcel Müller
Webentwicklung / Projektmanagement
eMail: m...@aikme.de

[http://static.aikme.de/mail/sig.jpg]

aikme GmbH
Rheinstraße 43-45
55116 Mainz / Deutschland
Telefon: 06131 92 06 503
Telefax: 06131 92 08 334
www.aikme.de


aikme GmbH
Geschäftsführer: Sascha Coldewey
Sitz in Mainz, Registergericht: Mainz
Registernummer: HRB 44835
Umsatzsteuer ID: DE282561622

Am Dienstag, 21. Januar 2014 um 08:31 schrieb Roman Allenstein:

Hi folks,

me and my team are developing a concept for us, how to develop modules
for oxid. We are now at the point where we have to decide to develope a
connector-module for all our coming modules or not.

We know that some agecies use their own connector to integrate their
modules in oxid. And i am pretty unsure if this is the way to go because
oxid provides a standardized way to integrate modules.

Whats your pros and cons for using an own connector?

Greets
Roman
--
Dipl.Winf. (FH) Roman Allenstein
Sales Manager E-Commerce
Spark 5 GmbH
Lutherstraße 7
27570 Bremerhaven

Fon: +49-471-4836-3547
Fax: +49-6151-8508-111

Mail: roman.allenst...@spark5.de
Web: http://www.spark5.de
--

Geschäftsführer:
Dipl. Designer Till Middelhauve
Dipl. Informatiker Witold Wegner
Amtsgericht Darmstadt, HRB 7809

Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general




___
dev-general mailing list
dev-general@lists.oxidforge.orghttp://dir.gmane.org/gmane.comp.php.oxid.general

___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Pros and cons for module-connectors

[Joscha Krug | marmalade GmbH]

Hi,

same for me: I also don't like them. If you have dependencies between
modules go for composer or something the like.

Best would be if OXID could come up with an extension in the
metadata.php in which you could tell "this module is based on that other
module".

Best regards

Joscha


//-
 
Joscha Krug
marmalade GmbH
 
www.marmalade.de 
k...@marmalade.de 
 
Leibnizstr.25
39104 Magdeburg
GERMANY
 
phone: +49 (0) 391 / 559 22 104
fax:  +49 (0) 391 / 559 22 106

*OXMOB | mobile Template
*
Das einfach geniale OXID eShop Modul.
Ab sofort in unserem Online-Shop

erhältlich.

Am 21.01.2014 08:44, schrieb Marcel Müller:
> Hey!
>
> I don't like such additional connector modules. They have their own
> bugs and generating system-wide errors, mostly. Especially when the
> module has an own style and/or database tables far from oxid. I had
> scenarios within a customer tried to remove a connectors modul and
> gets a lot of trouble with the system. But if you want to get rich
> with support, this could be a model ;)
>
> What about a wrapper script inside every module or inside the vendor
> structure? With that you can also check the versions and be agile.
>
> *Mit freundlichen Grüßen*
>
> Marcel Müller
> Webentwicklung / Projektmanagement
> eMail: m...@aikme.de 
>
> 
>
> aikme GmbH
> Rheinstraße 43-45
> 55116 Mainz / Deutschland
> Telefon: 06131 92 06 503
> Telefax: 06131 92 08 334
> www.aikme.de 
>
> aikme GmbH 
> Geschäftsführer: Sascha Coldewey 
> Sitz in Mainz, Registergericht: Mainz 
> Registernummer: HRB 44835 
> Umsatzsteuer ID: DE282561622 
>
> Am Dienstag, 21. Januar 2014 um 08:31 schrieb Roman Allenstein:
>
>> Hi folks,
>>
>> me and my team are developing a concept for us, how to develop modules
>> for oxid. We are now at the point where we have to decide to develope a
>> connector-module for all our coming modules or not.
>>
>> We know that some agecies use their own connector to integrate their
>> modules in oxid. And i am pretty unsure if this is the way to go because
>> oxid provides a standardized way to integrate modules.
>>
>> Whats your pros and cons for using an own connector?
>>
>> Greets
>> Roman
>> -- 
>> Dipl.Winf. (FH) Roman Allenstein
>> Sales Manager E-Commerce
>> Spark 5 GmbH
>> Lutherstraße 7
>> 27570 Bremerhaven
>>
>> Fon: +49-471-4836-3547
>> Fax: +49-6151-8508-111
>>
>> Mail: roman.allenst...@spark5.de 
>> Web: http://www.spark5.de
>> --
>>
>> Geschäftsführer:
>> Dipl. Designer Till Middelhauve
>> Dipl. Informatiker Witold Wegner
>> Amtsgericht Darmstadt, HRB 7809
>>
>> Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte
>> Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder
>> diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
>> Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
>> die unbefugte Weitergabe dieser Mail sind nicht gestattet.
>>
>> This e-mail may contain confidential and/or privileged information. If
>> you are not the intended recipient (or have received this e-mail in
>> error) please notify the sender immediately and destroy this e-mail. Any
>> unauthorised copying, disclosure or distribution of the material in this
>> e-mail is strictly forbidden.
>> ___
>> dev-general mailing list
>> dev-general@lists.oxidforge.org 
>> http://dir.gmane.org/gmane.comp.php.oxid.general
>
>
>
> ___
> dev-general mailing list
> dev-general@lists.oxidforge.org
> http://dir.gmane.org/gmane.comp.php.oxid.general

___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Pros and cons for module-connectors

[Marat Bedoev]

Hello,

i prefer to keep modules as simple as possible and so i’m against extra module 
connectors.
One day you will have a module, that requires some changes in your connector, 
and the change in the connector will require to update all your modules.

Cheers,
Marat

Von: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Marcel Müller
Gesendet: Dienstag, 21. Januar 2014 08:44
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Pros and cons for module-connectors

Hey!

I don’t like such additional connector modules. They have their own bugs and 
generating system-wide errors, mostly. Especially when the module has an own 
style and/or database tables far from oxid. I had scenarios within a customer 
tried to remove a connectors modul and gets a lot of trouble with the system. 
But if you want to get rich with support, this could be a model ;)

What about a wrapper script inside every module or inside the vendor structure? 
With that you can also check the versions and be agile.


Mit freundlichen Grüßen

Marcel Müller
Webentwicklung / Projektmanagement
eMail: m...@aikme.de
[http://static.aikme.de/mail/sig.jpg]

aikme GmbH
Rheinstraße 43-45
55116 Mainz / Deutschland
Telefon: 06131 92 06 503
Telefax: 06131 92 08 334
www.aikme.de


aikme GmbH
Geschäftsführer: Sascha Coldewey
Sitz in Mainz, Registergericht: Mainz
Registernummer: HRB 44835
Umsatzsteuer ID: DE282561622

Am Dienstag, 21. Januar 2014 um 08:31 schrieb Roman Allenstein:
Hi folks,

me and my team are developing a concept for us, how to develop modules
for oxid. We are now at the point where we have to decide to develope a
connector-module for all our coming modules or not.

We know that some agecies use their own connector to integrate their
modules in oxid. And i am pretty unsure if this is the way to go because
oxid provides a standardized way to integrate modules.

Whats your pros and cons for using an own connector?

Greets
Roman
--
Dipl.Winf. (FH) Roman Allenstein
Sales Manager E-Commerce
Spark 5 GmbH
Lutherstraße 7
27570 Bremerhaven

Fon: +49-471-4836-3547
Fax: +49-6151-8508-111

Mail: roman.allenst...@spark5.de
Web: http://www.spark5.de
--

Geschäftsführer:
Dipl. Designer Till Middelhauve
Dipl. Informatiker Witold Wegner
Amtsgericht Darmstadt, HRB 7809

Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general