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:
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
roman, what´s your reason why you would use/create an own connector?
Von: Joscha Krug | marmalade GmbH k...@marmalade.demailto:k...@marmalade.de
Antworten an:
dev-general@lists.oxidforge.orgmailto:dev-general@lists.oxidforge.org
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
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
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:
*
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
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
Hi,
i think it wasnt changed, its 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
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
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:
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:
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',
13 matches
Mail list logo
