What's your approach to starting a new extension?
We create a lot of extensions. Most are small-time plugins or modules for clients, but we do the larger component releases every few months (or try to at least).
Since there is a lot of 'required, but same' code across a component, we created an internal tool to create the framework/skeleton of a component for us. We can input a table name, columns, and a few other niceties and the basic output will be the front-end and admin table, model, and view files which allow for listing and editing the rows in a table. The next step is then to gut this code and start making it do what we want it too.
Our generator is useable to 'us', but not to the rest of the world in its current state. Not sure if anyone would want it anyways. We've also be recently investigating Nooku as it cuts down a lot on the required 'standard' code for an MVC development. However, with library frameworks, there's other concerns we have, though it's very impressive in its current state.
Anyways, really just trying to figure out what other people's best approach to starting a new extension is? Start from scratch, modify something existing, other?
Since there is a lot of 'required, but same' code across a component, we created an internal tool to create the framework/skeleton of a component for us. We can input a table name, columns, and a few other niceties and the basic output will be the front-end and admin table, model, and view files which allow for listing and editing the rows in a table. The next step is then to gut this code and start making it do what we want it too.
Our generator is useable to 'us', but not to the rest of the world in its current state. Not sure if anyone would want it anyways. We've also be recently investigating Nooku as it cuts down a lot on the required 'standard' code for an MVC development. However, with library frameworks, there's other concerns we have, though it's very impressive in its current state.
Anyways, really just trying to figure out what other people's best approach to starting a new extension is? Start from scratch, modify something existing, other?
Views: 39
Replies are closed for this discussion.
Replies to This Discussion
-
Permalink Reply by Júlio Pontes on -
Hi Alex,
I bet on some ideas that are changing the very way I like seeing the development and application architecture. as DDD, DSL, TDD and so on .. I even have some ideas maybe not so specific to the construction of components but they will surely cause a major impact on application development in general, be it component, an application (site), etc.. Surgin are always new trends and with that you have new ideas of how this can improve the development and maybe even change a little the vision of your application. I am proposing some very interesting things for Joomla! but this involves studies.. In my application I try to use the best practices and apply these new things they are studying, learning. -
-
Permalink Reply by Radek Suski on -
UML Design in EA -> Coding -> Reverse Engineering -> Changes in UML -> Coding -> Reverse Engineering -> Changes in UML -> Coding -> ....... Something like this ;-)
In most cases the first UML design isn't perfect so while the development has to be changed many times. -
-
Permalink Reply by Torkil Johnsen on -
So if you have a generator that generates a component foundation, do you also have generators that fix all these generated components when a bug in the component generator is found? Sounds like hard work! Using the Nooku Framework is my new preferred approach. Having common framework code as a foundation for your extensions sure beats scaffolding, I used to do that too...
-
-
Permalink Reply by Alex Andreae on -
Torkil:
Yeah, that's exactly what I was asking. Of course we've found bugs, which are usually minor. Then we fix the generator so it outputs better code the next time and fix any uses of that code as necessary. The alternative is to start from a blank file and find new bugs with each new component. At least this way, we usually know where to look for 'common' issues when they arise.
That's really the heart of the question though, what's the best way to start developing the extension. While the UML mechanics are good for scoping out an idea, and DDD/MVC and other coding styles/ideals are there for how to code once you begin, my main point was that when you actually start coding, where do you start? A blank .php file, or some other skeleton code (whether generated specifically for your project, or a few classes with empty functions to help you get started).
I totally agree that Nooku and some of the others provide a great common framework and reduce/eliminate the need for a generator like ours (we'll be glad to get rid of it).. but with the current Joomla! MVC structure, getList(), table files, basic pagination queries, listing and edit views for your tables in the back-end still need a bit of code to start off with. That's what we generate to get us started, and again, it's just a starting point to help us make sure our DB is setup, the tables are there and we can enter some sample data easily before we try to start using/manipulating it in our code. -
-
Permalink Reply by Amy Stephen on
-
Alex - I appreciate the question as it's discussions like this I was hoping we'd have. It's so obvious we are all on the same journey and sharing approaches is smart. I don't think there is a "right way", but good approaches do tend to shake out.
I am also working on this, and after some time thinking and coding and recoding (and still working), I am pretty happy with directions I am going. There are three distinct techniques I am using: a common content object, common application code (meaning Components and Modules), and a centralized library where business logic is stored (my plugins are really all collapsed into this Library).
The common content model supports a broad range of information, including events, articles, media, messaging, etc., and it enables maximum code re-use.
The common code approach is likely close to what you are describing. My Components are all the same code base, with the exception of the names of Classes, filenames, etc., The point is that anything that can be, is generated from parameter values. Otherwise, there is a one word that must be changed in several places for each Component.
My library is where differences in content type are managed. So, for an image gallery, these rules apply, for an article, these rules apply, all logic driven by a common set of parameters.. At the heart of my library is a core process, or set of "content management actions" that can are taken on "generic content." it's distilled down to areas like Broadcasting, Categorization, Protection, Response, etc., so that all content is processed by the same code base and same set of parameters with different values establish different treatments.
When I finish, I need to look closely at what Martin is doing and also take a closer look at Nooku. To be honest, I don't think Nooku is going to be a good fit for me since I won't be redoing my Components. But Martin has managed to do something I need to do, and that is store the entire structure and reuse it as a process. That's likely more useful to me, given the approach I'm taking.
Again, I'm *certainly* not saying my approach is correct but I am very interested in looking at this question and seeing what others are doing since this is *exactly* where we benefit from community. I'll of course share more later. Thanks Alex for this question and your introduction. Keep it coming. -
-
Permalink Reply by Martin Rasser on
-
I guess the issue is about not including other peoples code in commercial packages. A nice way to get MVC structure stubs together quickly is the MVC Generator from Alpha Plug.
Also have a look at this blog entry here. This is a light-weight library that deals with almost all backend business in a generic, yet customizable way. Today, I created a backend for an image gallery component with this library in about 15 minutes. All Joomla typical MVC, grid, validation etc, even multilingual. If any extra functionality is needed, you can simply override the parent's methods. For the frontend you just need to pull data from the extended models and create templates to show your visitors something nicer than a var_dump() :)
I'm thinking about doing an online configurator for components, where people can simply pick and choose what they want to show in their components and have generic zoo-style frontend output to start with. -
-
Permalink Reply by Olle Johansson on -
I used to have a skeleton component that I made a copy of, and then run a little script which updated stuff like table names and such. When it's a plugin or a module, I usually just make a copy of an old one that's most similar to the new one I'm creating.
Haven't had time to look at Nooku yet, but anything that does all the standard work for you is good. If I create a new component, that's probably what I'd use.I've used Zend Framework a lot before, but that's a bit bulky.
I looked at an online Joomla component skeleton creator a while ago, which seemed to be pretty neat. Possibly the one Martin mentions.
I've thought about setting up a build system which can automatically generate a skeleton, create releases, run tests etc. But I haven't really had that much time to work on Joomla stuff lately.
Most components could probably also be easily done with a generic system that could be configured with xml or something. Just define the tables and fields, how they should be presented, acl roles, verifications etc. When there's a need for something specific, just override that part. -
-
Permalink Reply by Torkil Johnsen on
-
I've probably mentioned the Nooku Framework so many times now that it would be like whipping a dead horse to bring it back up :)
Still: Where code/scaffold generators generate standard code. Nooku eliminates the need for code and puts all the common stuff into a framework that is very extendable. For a standard component, most of what you need to do is to specify what type of controller to use (depending on if you are viewing or editing an item for instance) and make the output a bit nicer than var_dump. Component names are just compared to database table names according to specific naming convention, so models automatically know where to fetch their data.
Scaffolding generates the same code over and over and over again, for each application you create. When the scaffolding generator improves some of it's features or fixes some bugs, you need to patch all those components it created for you. Lots of code to maintain. Ugh. It's totally un-DRY man! More like D(i)R(t)Y! :)
Okay, I'll stop with the Nooku propaganda already. I do not get referral points for doing so either :) I've just been down the road you're heading down right now with the scaffolding, so I thought I should share with you what I learned from the experience. Plus: Two developers working on one framework is much better than two developers working on two separate scaffolding scripts… From what this discussion brings it sounds like there are four or five different scaffolding scripts floating around only among those who replied here, and all are probably solving the same kind of problems. -
-
Permalink Reply by Peter van Westen (NoNumber) on -
Note to self 1: Try out Nooku
Note to self 2: Try to get some time to do note 1
Note to self 3: If note 2 fails, try out Nooku to safe the time needed for note 1 -
-
Permalink Reply by Alex Andreae on
-
You don't have to stop with Nooku propaganda. I was going through examples last night, and definitely impressed with reduction in code-redundancy. That's the exact point I have. I don't like our generator. I don't want to use it anymore, but until Nooku came along, it was necessary.
That's not to say that Nooku solves everything either (especially in it's current state).. which is where I wanted to start this post and get the ideas and feedback about what others were doing. Not the style of coding itself, but when you sit down to code, do people actually start with a completely blank slate/php file anymore, do they take a skeleton code that they created/generated, or do they gut a previous extension to start with something that already has x% of features they need.
I find that especially when I'm teaching new people how to create a component, that the distinction between MVC sounds great on paper, but in reality there's also table files, template files, and other things that start to confuse the situation again (I still thank Johan everyday for bringing us out of Joomla 1.0 hell and giving some structure to extensions though). Nooku solves this by (for example) abstracting tables on the fly.. but I can still imagine a day where Nooku will be at a state where a generator of some sort will be nice, even if it's generating much less code.
When you speak of un-DRY because when you find a bug you have to patch everything, the same goes for when you copy your favorite function from a previous extension and find a bug. Scratch or framework generation each have their issues. Not saying your point isn't valid though. -
-
Permalink Reply by Shayne Bartlett on -
I'm biased, but I would always start from scratch and use Nooku. The most I would take from an existing extension would be idea's and concepts. But the code would be fresh.
An interesting development within the community of devs using Nooku is an increasing amount of code sharing. Especially the little bits that we all use over and over. There's also a very active skype channel which is a great place to bounce ideas and concepts around. Not dissimilar to the Joomla! developers forum but in real time. This stuff may seem like fluff but its actually very helpful through out the development process. -
-
Permalink Reply by Scott Cooper on -
I'm not much of a developer...only follow discussions like this on a very conceptual level, but I have what may be a very dumb question: why isn't/wasn't the Nooku framework developed as part of the Joomla core, as opposed to an extension of it?
-
© 2012 Created by Amy Stephen.
