FuelPHP Forums

That's a very long post, I will try to give you some feedback on these points.

Upload:

 1.6 will have a completely rewritten Upload class, which will use a file object for each file uploaded, which you can access individually or as a group, depending on how you name them. For example, if you have four fields with name "file[]", when you ask for File objects named "file", you will get all four. It will also allow you to apply a different config for each file.

Cascade delete:

Will work on any relation you enable it on. Usually, it will only make sense on everything but a belongs_to (if you delete a child, you normally don't want to delete the parent). It cascades (as the name implies), so be careful on which relation you define it.

Observers:

There is no need to extend existing observers, they do a specific task, and there's no reason to modify them. As for writing observers, http://fuelphp.com/docs/packages/orm/observers/intro.html tells you how to add an observer to a model. If you have created your observer according to http://fuelphp.com/docs/packages/orm/observers/creating.html in app/classes/observer/test.php, you would use "Observer_Test" as observer name in your model definition. After all, it's a class as any other. In your example, you should attach the observer to the "before_delete" event.

Asset groups

I don't understand what you mean with asset groups. But then again, I don't know Casset. If this is about saying "I have an asset group called "header", and I want to add these three CSS files, and these two JS files, and then in your page template render the entire group in one go, you can already do that with the Asset class. If you mean something else, please explain.

Modules and HMVC

Modules is pretty strait-forward. A module has exactly the same structure as app. It only lives in a namespace, and the namespace must be equal to the module name. As for routing, where an app controller is accessed using http://yourhost/controller/method/params, you access a module using http://yourhost/module/controller/method/params. As to HMVC, it's nothing more then manually coding the request normally initiated by the browser, using the Request class.

Documentation

We are very aware that the docs at the moment are very clinical, and very geared towards API documentation. This is going to change. For the upcoming v2.0, the documentation will be more in book-style, with concepts, how-to's and explanations. There will be separate API docs, which are already available via this website.

The current docs are hard-coded in HTML, which makes maintenance very hard. The new docs will be written in markdown, which is a lot easier for people to learn and use. And since github supports online editing and a markdown editor, it will be very easy to fork the docs repository, edit the page online, and send a pull request back with your changes. Without using any git locally. We hope this will increase the number of contributions from the community.

Writing documentation is hard work, and takes up a lot of time. Writing good documentation is even harder. We're only a small team, not company funded like most other frameworks, so we can't do everything ourselfs. So sometimes we have to take shortcuts, and documentation unfortunately has been one of them.

Absolutely right. Now let's find someone to make them... :)