Couple of questions
Permalink 1 user found helpful
1) do versions in relation to 5.6 addons matter? Or can I rewind some? I am likely going to change my icons for 5.7 products and would like to soften version numbers as well. ProBlog is on v13 officially. I'd love to make that v2.
2) How do you register package and block assets and asset groups for proper loading now? For example - for a block that has a dialog and core css.
3) I am still not happy with app structure in 5.7 regarding AJAX views. Right now I am getting by with a registered route and then an element file per view. But I could use some guidance on the correct View::make(). I've tried several iterations of this without success. Ideally I would like to see my ajax views in /packages/packagename/blocks/blockname/ajax/viewname.php. Andrews likethis example places the view in a root view dir...this feels messy to me after you get 10 or so views. It's also not relative enough in my opinion.
4) related to #3, how do / what is the process for end users to override my ajax views now?
Many thanks.
ChadStrat
2) How do you register package and block assets and asset groups for proper loading now? For example - for a block that has a dialog and core css.
3) I am still not happy with app structure in 5.7 regarding AJAX views. Right now I am getting by with a registered route and then an element file per view. But I could use some guidance on the correct View::make(). I've tried several iterations of this without success. Ideally I would like to see my ajax views in /packages/packagename/blocks/blockname/ajax/viewname.php. Andrews likethis example places the view in a root view dir...this feels messy to me after you get 10 or so views. It's also not relative enough in my opinion.
4) related to #3, how do / what is the process for end users to override my ajax views now?
Many thanks.
ChadStrat
bump.
I don't have an official answer for you, but I think the version will still be related at least, since that is used on the server to determine to which c5 version your addon is served.
That said, it could be changed as currently, addons are not really meant to evolve differently regarding the c5 version they are targeted...
That said, it could be changed as currently, addons are not really meant to evolve differently regarding the c5 version they are targeted...
I'd also like to hear some insight on the architectural side of 5.7 add-ons. Documentation would be great of course, but from history I doubt that's the first thing we'd get.
A reference implementation of an add-on would be great. I know there's the one in Andrew's blog but as of my understanding it does not demonstrate how to deal with custom libraries, helpers, models (and their schema), etc. (+ the points already raised here). So if possible, it'd be great to see a reference implementation covering all these parts.
There might be something I have missed though, haven't checked the forums for a while. At least in the blog posts I didn't see any additional information than what I have already seen.
We haven't even started with converting our add-on's to 5.7 as we've waited for something like this to be available.
Just for the reference, I've already seen and read these:
http://www.concrete5.org/documentation/how-tos/developers/concrete5...
http://www.concrete5.org/documentation/how-tos/developers/concrete5...
Just when developing more complex add-ons, I think it would be good to know a bit more on the architectural decisions that Andrew has had in his mind regarding add-on development. We can always dig into the core code but it might not reveal everything related to packages and their designed architecture.
I'm personally feeling currently almost the same as when I started with my first add-on for the older versions but back then, there were much more resources (i.e. docs, how-to's) and reference implementations (i.e. open source add-ons) available. Probably I'd be a bit wiser when digging into the 5.7 code but a reference implementation would not hurt at all.
Antti
A reference implementation of an add-on would be great. I know there's the one in Andrew's blog but as of my understanding it does not demonstrate how to deal with custom libraries, helpers, models (and their schema), etc. (+ the points already raised here). So if possible, it'd be great to see a reference implementation covering all these parts.
There might be something I have missed though, haven't checked the forums for a while. At least in the blog posts I didn't see any additional information than what I have already seen.
We haven't even started with converting our add-on's to 5.7 as we've waited for something like this to be available.
Just for the reference, I've already seen and read these:
http://www.concrete5.org/documentation/how-tos/developers/concrete5...
http://www.concrete5.org/documentation/how-tos/developers/concrete5...
Just when developing more complex add-ons, I think it would be good to know a bit more on the architectural decisions that Andrew has had in his mind regarding add-on development. We can always dig into the core code but it might not reveal everything related to packages and their designed architecture.
I'm personally feeling currently almost the same as when I started with my first add-on for the older versions but back then, there were much more resources (i.e. docs, how-to's) and reference implementations (i.e. open source add-ons) available. Probably I'd be a bit wiser when digging into the 5.7 code but a reference implementation would not hurt at all.
Antti
I too have yet to port any of my addons to 5.7. Partly because I am too busy with other work. Also because of lack of documentation or guidance on building anything but the most basic packages.
Without any documentation or guidance, I would have to work everything out the hard way. With documentation and guidance, the work involved is considerably less. Hence I am waiting as long as possible on the hope that as more documentation is published the work involved in updating my addons to 5.7 will reduce.
More generally, in a few days time the PRB will be expected to review packages for 5.7. Yet we have no guidance on the best practices to evaluate a 5.7 submission against.
Without any documentation or guidance, I would have to work everything out the hard way. With documentation and guidance, the work involved is considerably less. Hence I am waiting as long as possible on the hope that as more documentation is published the work involved in updating my addons to 5.7 will reduce.
More generally, in a few days time the PRB will be expected to review packages for 5.7. Yet we have no guidance on the best practices to evaluate a 5.7 submission against.
1. 5.7 add-ons are going to be completely separate, in a completely separate marketplace. So old version numbers will have no bearing on new versions numbers. They're completely separate marketplace item records. (They will however be able to use the sample handle.)
2. You're going to want to explore using the new asset system. I have a screencast in the works about this but it's waiting for us to get 5.7.1 out the door. Here's an example of registering an asset named "bootstrap/tab" in a particular package:
3. You can add sub-directories in your views, the same way we do in the core.
4. Overrides of these views in the root should still work (although I haven't verified recently, we should test this with 5.7.1.)
2. You're going to want to explore using the new asset system. I have a screencast in the works about this but it's waiting for us to get 5.7.1 out the door. Here's an example of registering an asset named "bootstrap/tab" in a particular package:
$al = AssetList::getInstance(); ## Register Bootstap tab.js $al->register( 'javascript', 'bootstrap/tab', 'blocks/formigo_containers/js/bootstrap/tab.js', array('version' => '3.2.0', 'position' => Asset::ASSET_POSITION_HEADER, 'minify' => false, 'combine' => false), $this );
3. You can add sub-directories in your views, the same way we do in the core.
4. Overrides of these views in the root should still work (although I haven't verified recently, we should test this with 5.7.1.)
