Extension development

Next topic

Author	Message
Jérôme m	Monday 04 October 2010 4:18:53 am I developed a couple of very specific extensions for my own use. I'm facing a couple of general problems developing extensions and using other people extensions as well witch is the lack of an "official howto". for example : If I have to handle http inputs, where should I handle that ? In an action ? inside a class ? That kind of things is handled in very different ways in the various extensions I used witch makes it difficult to understand the code and adapt it. It also leads to write a lot of code for buiding functions that already exist in the core. For example, I recently used an extension redefining a custom datatype for structuring data that are already handled by ez (dates, booleans, etc.). That leads to write very much code and braking the compatibilité with fetch functions. I'm also sometimes very surprised to see some general purpose labels like "Remove selected" being translated in the core and in every extension. I'm often reading advices like "read other people's code", or "study the kernel files" or "use ezdebug" and that's of course very usefull. The only benefit of using a structured expandable system is to be able to use it without having to undertand the whole thing. Il read a few articles about developing extensions and my question is not "how should I do this or that ?" but is there some sort of "offical" guideline document about that.
Damien Pobel	Monday 04 October 2010 5:32:14 am Hi Jérôme, " for example : If I have to handle http inputs, where should I handle that ? In an action ? inside a class ? That kind of things is handled in very different ways in the various extensions I used witch makes it difficult to understand the code and adapt it. " It depends on your need. If you want to store data in content object you usually need to write a datatype. If you just want to do a specific custom action, you have to do a module/view and if you want to plug your code into an eZ Publish process you'll need to write workflow event type or a custom action or a content edit handler. And there are probably others situations that I do not have in mind currently :-) " It also leads to write a lot of code for buiding functions that already exist in the core. For example, I recently used an extension redefining a custom datatype for structuring data that are already handled by ez (dates, booleans, etc.). That leads to write very much code and braking the compatibilité with fetch functions. " it's probably needed to fix a limitation of eZ Publish. For instance, the Date datatype is not able to store dates before 1970-01-01 that's why the birthday extension exists. " I'm also sometimes very surprised to see some general purpose labels like "Remove selected" being translated in the core and in every extension. " In fact, the same sentence in english can be translated in different locale strings depending on the context. " Il read a few articles about developing extensions and my question is not "how should I do this or that ?" but is there some sort of "offical" guideline document about that. " hum it's difficult to write a doc that covers all the possible cases. So feel free to ask questions in this forum, I think you should always find someone to help you. Cheers Damien Planet eZ Publish.fr : http://www.planet-ezpublish.fr Certification : http://auth.ez.no/certification/verify/372448 Publications about eZ Publish : http://pwet.fr/tags/keywords/weblog/ez_publish
Jérôme m	Wednesday 06 October 2010 4:59:29 am Merci Damien, The fact is : there is an expandable system that needs extensions code to respect certain conventions to function properly. Plus there is a whole system that implements a lot of things allready. I used an extension that needs to process user posted data. The processing (capture of http vars + various actions) is done inside a class and triggered by a fetch method. The problem is : when the view cache is working the fetch doesn't occur anymore and the processing is not working. My example is trivial but illustrates the fact that if one doesn't realize one's extension is not fully 'compatible" with the system it's supposed to work with, users are going to spend time solving problems and might even give up and say it's lousy even though it does basically everything they need. A simple rule could be : handle user posts in that place : ... you can be sure it works 99% of the time. Rules for making fully compatible extensions => it works immediatly, isn't it what everybody wants ? I agree that no rule can apply 100%, 99% is far enough. About asking to people what they would do in this or that situation, I really preffer to know what is made to work that way than relying on what is known to work.

Author

Message

Monday 04 October 2010 4:18:53 am

I developed a couple of very specific extensions for my own use.

I'm facing a couple of general problems developing extensions and using other people extensions as well witch is the lack of an "official howto".

for example : If I have to handle http inputs, where should I handle that ? In an action ? inside a class ?

That kind of things is handled in very different ways in the various extensions I used witch makes it difficult to understand the code and adapt it.

It also leads to write a lot of code for buiding functions that already exist in the core. For example, I recently used an extension redefining a custom datatype for structuring data that are already handled by ez (dates, booleans, etc.). That leads to write very much code and braking the compatibilité with fetch functions.

I'm also sometimes very surprised to see some general purpose labels like "Remove selected" being translated in the core and in every extension.

I'm often reading advices like "read other people's code", or "study the kernel files" or "use ezdebug" and that's of course very usefull. The only benefit of using a structured expandable system is to be able to use it without having to undertand the whole thing.

Il read a few articles about developing extensions and my question is not "how should I do this or that ?" but is there some sort of "offical" guideline document about that.

Damien Pobel

Monday 04 October 2010 5:32:14 am

Hi Jérôme,

for example : If I have to handle http inputs, where should I handle that ? In an action ? inside a class ?

That kind of things is handled in very different ways in the various extensions I used witch makes it difficult to understand the code and adapt it.

It depends on your need. If you want to store data in content object you usually need to write a datatype. If you just want to do a specific custom action, you have to do a module/view and if you want to plug your code into an eZ Publish process you'll need to write workflow event type or a custom action or a content edit handler. And there are probably others situations that I do not have in mind currently :-)

it's probably needed to fix a limitation of eZ Publish. For instance, the Date datatype is not able to store dates before 1970-01-01 that's why the birthday extension exists.

I'm also sometimes very surprised to see some general purpose labels like "Remove selected" being translated in the core and in every extension.

In fact, the same sentence in english can be translated in different locale strings depending on the context.

Il read a few articles about developing extensions and my question is not "how should I do this or that ?" but is there some sort of "offical" guideline document about that.

hum it's difficult to write a doc that covers all the possible cases. So feel free to ask questions in this forum, I think you should always find someone to help you.

Cheers

Damien
Planet eZ Publish.fr : http://www.planet-ezpublish.fr
Certification : http://auth.ez.no/certification/verify/372448
Publications about eZ Publish : http://pwet.fr/tags/keywords/weblog/ez_publish

Jérôme m

Wednesday 06 October 2010 4:59:29 am

Merci Damien,

The fact is : there is an expandable system that needs extensions code to respect certain conventions to function properly. Plus there is a whole system that implements a lot of things allready.

I used an extension that needs to process user posted data. The processing (capture of http vars + various actions) is done inside a class and triggered by a fetch method. The problem is : when the view cache is working the fetch doesn't occur anymore and the processing is not working.

My example is trivial but illustrates the fact that if one doesn't realize one's extension is not fully 'compatible" with the system it's supposed to work with, users are going to spend time solving problems and might even give up and say it's lousy even though it does basically everything they need.

A simple rule could be : handle user posts in that place : ... you can be sure it works 99% of the time.

Rules for making fully compatible extensions => it works immediatly, isn't it what everybody wants ?

I agree that no rule can apply 100%, 99% is far enough.

About asking to people what they would do in this or that situation, I really preffer to know what is made to work that way than relying on what is known to work.