FuelPHP Forums

#Phil F

Hi all, Are there currently any suggested guidelines around the development of Packages / classes / addons / modules etc that are developed for general release? Should they be developed so that they do not rely on any other Packages / classes / addons / modules etc so are in essence a standalone product to allow more flexibility and appeal to a wider audience? For example:
Anything with any form of database access should be primarily designed for the lowest level of database interaction available (\DB::stuff) in the first instance then offer additional switches for other packages such as Orm. I would be interesting to hear other peoples thoughts on this. Phil.

Jelmer Schreuder

Personal opinions, not official Fuel guidelines - though I'd expect they'd look something like this if we had them: - Packages are better than modules for sharing
- Keep your code modular and easily extended
- Make sure changes/extensions can be made from the app or another package, don't ever require people to change the package! Otherwise updating would be a huge pain each and every time, while Fuel offers more than enough options to extend from the outside.
- Only depend on the Core, unless you have very good reason to depend on another package - if you do make sure it's not something many people will use many different things for
- If you use something that people might use different tools for, try to make it use drivers and be sure it's extendable. Examples for drivers can be found in the core with Session and Cache classes, or the Auth package with Login, Group & Acl drivers. All of which are extendable from the app.
- Only include presentation code as examples, don't put presentation in any part that the user of your package might need to change. Unless meant specificly for building UI elements of course.

Anything with any form of database access should be primarily designed for the lowest level of database interaction available (\DB::stuff) in the first instance then offer additional switches for other packages such as Orm.

In this case I'd probably choose the DB option but have it in a driver which could be easily extended to use other retrieval options. Make sure the data storage parts of your class can be replaced without needing to copy paste entire methods that only have small bits related to the storage.

#Phil F

Jelmer, Thank you for the concise answer. I agree with the majority of your statements especially the develop firstly for the \DB::stuff. The only one I might question is the statement "Packages are better than modules for sharing" though as I see them as different solutions to suit different requirements. A big plus for modules is that they are plug and play and can simply be dropped in to the modules directory and are then immediately available for use. I believe that many more modules will be written and released in to the Fuel community than packages as time goes by as they are basically simple plug and play solutions. People like easy and will always go with the quickest and simplest way to fulfil the requirement they have. I suppose that this could also apply to a simple class that someone has written. I am in a quandary now about a generic solution for something like a blog for example. Module or Package hmmmm??? I would really like to hear what other peoples thoughts are on this subject. Do you think you will develop and release to the Fuel community more packages or more modules?

Harro

I have to agree with you Phil. For me, packages provide "core" functionality, they add new functionality to the core which you application code can use. Modules provide "app" functionality, they contain controllers, views, models, application logic. I think there's a place for both, and something we need to think about when we start will cells (which I think is targeted towards packages only at the moment).

Jelmer Schreuder

Ok the "Packages are better for sharing" comment was a bit too strong. My basic point is that if you want to share something that's really usefull for many it shouldn't implement too specificly and be very extendable. Both of which are best implemented as a package. Of course there's a place for both packages and modules, though I'd expect I would be more interested in packages from others than modules. The reason is that my modules tend to be specific to my base-backend I've build on top of Fuel (CI in the past) and integrate drop-in, something which could never work with code from others. But that's in part how different devs use modules in different ways.

nerdsrescueme

The way I figure it, if I'm extending core and adding Fuel functionality... create a package. If I'm creating a website specific feature like a blog or forums, them create a module...

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.

Howdy, Stranger!

Categories

In this Discussion