I would like to lay down few questions about versions and new things that in fuelphp framework.
1. Will the version 1.3 be built in the way that core will be package?
2. Will the version 1.3 will cope with packages from composer/packagist?
3. Will image and email component be dropped like the orm? If so when?
4. Which version to pick up to start development?
5. How to create multiple applications? app folder is like a global place where multiple applications in live in module directory and can have their own modules?
6. About the structure the is a folder classes with subfolder view and folder views outside of it. Do i get it right when view is for view classes and views is for html templates when using template engine?
Thanks
1. No, there will not be any structural change in 1.x.
2. FuelPHP supports PSR packages since v1.1, so you can do that now.
3. Nothing is being dropped, they are being deprecated. Probably as of 2.0 we will suggest alternatives for new projects.
4. I always use the latest develop version for all my development.
5. Depends on your definition of 'multiple applications', so not easy to answer.
6. classes/view is for Viewmodel classes, views is for view files.
As to point 2, you need to register the packages namespace to the autoloader, indicating it's a PSR package. After that, the autoloader can find and use the classes in the package.
As to point 4, in general develop it's more stable then the latest release version, but occasionally a bug is introduced, which usually is found and fixed without hours, as more people develop on the develop branch.
5. I mean for example two applications. Web and CMS. How to structure it to be able to share models but each should have its own modules?
6. Where then should i put raw html templtes? In view classes I want to put logic connected to rendering such as creating blocks in template (smarty/twig) etc.
About the versions, I found at packagist two packages fuel/core and fuel/kernel. What is the difference? I would like to develop only with necessary core components + packages from apckagist but when i browser kernel classes such as sessions, inflector etc were missing.
Do you suggest to take this approach with develop version and do the same?
Thanks for your kind replies.
If they are that integrated that they share models, I don't really see it as two applications, but more a frontend and backend of a single application. If you want to split them towards the user using two hostnames, have them point to the same docroot, and use rewrite rules (for example to map /admin to the root of your CMS hostname, and block /admin for the other hostname).
View files are html templates. There is no such thing as "view classes" in FuelPHP. The View class is simply a wrapper for your view file so you can interact with it. If you need template functionality like partials, look at the Theme class, which will do that for you, and supports theming of your application.
You use the Viewmodel for prepping logic for your view, for example to convert a model object passed to an array for a dropdown in your view. This is code that should not be in a view file, a view file should contain as little code as possible.
The files on packagist are part of FuelPHP 2.0. In 2.0 the framework is split into the framework itself (the kernel) and a collection of core classes (the core) the framework needs to run. Think about classes like Uri, Arr, etc. Stuff in the 1.x core that is not required for the 2.0 framework to run (like for example Session or Cache) will be in separate repositories (and composer packages) that you can use, or use a different package that provides that functionality.
As 2.0 is still very much in development, the core is not complete yet, and most of the supporting packages are still in development. There are however people that run production apps on the current Kernel + Core, and some third party packages (like Doctrine) to fill in the missing bits.
We will keep supporting 1.x until after the release of 2.1, and once 2.0 is ready for release we will provide upgrade documentation and a set of legacy classes to translate the 1.x API to the 2.0 API, which will make it easier for you to upgrade an existing application.
Great thanks but now I im thinking about the structure. I want to divide frontend and backend and they will be separate modules. But each of them will have also another submodules. And i didnt found the module directory in supported structure for modules in here. http://docs.fuelphp.com/general/modules.html#/folder_structure
How am I suppose to deal with this? thanks.
Modules are self-contained application components, they can't have modules themselfs. But you can create an entire folder structure in the classes/controller folder, and give controllers sub-namespaces.
So a controller in modules/admin/classes/controller/users called Index can be in the namespace \Admin\Controller\Users. Instead of in the Admin namespace, and called Controller_Users_Index.
That seems to be a pretty ugly solution. That would mean i have to create separate folder in view and in model with name front end and backend and put files there. I loved fuel but this sound like a critical hit for me. Yii or Kohana for example support cascading unlimited. It is not on about controllers. How would you do it when I want to have frontend and backend as separate applications call it like that and they would have modules, configs, lang everything. Almost same structure as the app folder without cache or so.
On wiki is written that fuel has adopted kohana cascading filesystem while what I am trying to do is relying on it. So does fuelphp really support it?
I put it clear with image of file structure i want to lay down. In one post http://fuelphp.com/forums/topics/view/8861 somebody asked almost the same but it is not clear how he implemented the structure.
What I did:
- took app folder outside of fuel to separate it
- everything will be in the public_html folder because shared hostings.
- in app folder I have typical structure as master application or wrapper for everything.
- I added folder apps where I will create separate subaplications like web (frontend), cms (backend) and other (see image)
How to route it? eg. when I type domain/cms/... to use folder /app/apps/cms/... and when I type domain/contact to load controller contact from folder app/apps/web/classes/controller/contact.php ?
And application will have modules.
Image : http://www.kyzo.sk/fuel_structure.png
Fuel does support the cascading filesystem, that's basically what I described. You can put your controllers 10 levels deep if you want. All I said is that you can mix and match with namespace and classname, so you can create a more logical structure.
So these are equal as far as FuelPHP is concerned:
Class Controller_In_A_Very_Deep_Folder_Structure {}
// vs
Namespace \Controller\In\A\Very\Deep;
Class Folder_Structure {}
As far as routing is concerned, every folder is a URI segment, so the above is called as [url=http://yoursite/in/a/very/deep/folder/structure,]http://yoursite/in/a/very/deep/folder/structure,[/url] assuming you haven't gotten any routing that makes it look better...
But this has nothing to do with what you propose.
You can not make the folder structure in the image, at least not how you see it. Both app and all modules share the same folder structure, and you can not deviate from that. FuelPHP cascades inside the classes folder.
One solution I've seen to support multiple apps is to get the REQUEST_URI in your index.php, get the first segment, set APPPATH based on that, strip it, and update REQUEST_URI.
But that doesn't give you cross application HMVC, as there is only one application active at any given point.
If you really need full native framework support for multiple applications, you'll have to wait for 2.0, which already had that.
Thanks for reply.
Is already version 2.0 usable this way? If so Is there ani tutorial for it including changes in .htaccess?
All i want is to have main wrapper where mostly models, cache and maybe some configs would be and then multiple applications which could share models and some other files but then be completely independent.
Donate
