Projects / Bakery

This is pretty much what I was asking for in my ticket 5. However there are certain 'blob' areas that would be created with this structure, so either cross-referencing or further reorganization I feel is needed. Mainly, all items under Articles will be about as impossible to 'browse' as it is now. I would like to see a better approach to freely browsing so that you can slowly get closer to your solution. Tips/Tutorials/Cases should be grouped under what they pertain to (Component, model, app build). My question is should we put behaviors under models, components under controller or I feel at the very least GROUP them based on layer, and allow tutorials to fall under this organization? This may sound too complex as it can start to feel as a categorization matrix: Tutorial for Component, Tip for Model, Use case for Plugin, etc.

Here's a proposed structure: - Tutorials - Tools, Tips, Snippets - Case Studies - Code Which should be cross-referenced by which layer it pertains to with: - Model - Controller - View - Application (multiple, miscellaneous) So that a combination of the 2 will help you find your resource. Also note that 'Code' under 'Model' would automatically be a Behavior, 'Code' under 'Controller' would automatically be Component, 'Code' under 'View' is a Helper, and 'Code' under 'Application' is a plugin. I know it may be strange at first however I think looking forward this structure would promote the greatest accessibility.

I totally hear ya, ProLoser. I'd argue the problem, however, isn't so much in the current categorization as much as the user interface to move through the categories. That isn't to say we can't improve on the current categorization -- it makes a lot of sense, to me. I agree with the idea that we should think of ways to more specifically categorize articles rather than the blobs they are now. However, I'll provide some mockups soon would should make clear some mucher better ways to highlight and move about the code/content of the bakery. With regard to the code portion: I mentioned this in irc but not sure how many people agree; I strongly feel that the bakery 'code' section should not supply a standalone category for models, views, controllers or apps. Rather, it makes the most sense to me to have these as plugins -- If you want to share these pieces with the community, yes it takes a little more time to bundle an app as such. However, this is the exact purpose of plugins -- to be portable applications / pieces. This helps to better organize the code you're sharing, as well as avoiding naming conflicts (What if someone is sharing a Candy model and I already have one? With a plugin I can have my Candy model and use their CandyPlugin.Candy model with ease). Alkemann brought up two valid concerns -- 1) it takes a little more work to bundle an app as a plugin and, 2) There are certain technical limitations to plugins that do not exist with an app. I'd argue the first issue, though legitimate, should be considered necessary. I feel moving forward the bakery should encourage developers that want to share specific models/controller/views, collectively their app, as a plugin. If a developer doesn't want to put in the time to make it portable, Then an article is more appropriate than a code piece -- as they can explain what they made and supply the example. I see the code section being a place where I can go and quickly find portable, stable code I can use in my application. Behaviors, Components and Helpers are appropriate as they can apply to any of their respective cake layers -- but someone else's MCV by themselves just seems messy and adds to the bakery clutter. Second, though there may currently be technical limitations, such as the inablility to use a DataSource within a plugin, this will not be the case moving forward. In fact, there are workarounds to such issues already - as I have a plugin included with a plugin and in my instructions I explain it must be moved to the app's model/datasources folder. Not exactly cakey, but does that job and allows for portability with the plugin. Anyhow, just my two cents. What do you think?

Ah this is something myself and techno-geek have been pondering for some time now. We were unsure if it is considered the proper approach to bundle EVERYTHING into plugins, and I had initially not liked that idea until I learned you can use components/behaviors/helpers/etc out of plugins, making grouping much more relevent (and would be nice to see teams of scripts being consolidated into 1 plugin package). IF this is what the higher-ups would like, then it's good that techno-geek and I are gonna start pushing this form of development anyways. I still think we should encourage teamed development of plugins, like in drupal, but that is out of the scope of the bakery (although their 'bakery' features are what I aim for)

ProLoser: you should give this a gander: [Plugin Development Slides by Mark Story] (http://mark-story.com/downloads/view/plugin-development-cakefest-argentina)