Gregory, this kind of response is uncalled for. No need to be condescending or use foul language.
As for the original post, I can say that 1) I agree the MooTools core needs to stabilize. No more method renaming and changes need to be backwards compatible. At CNET, I spent a lot of time rewriting a lot of our code for 1.2. The compatibility layer helped with a lot of problems, but not all. Expect future versions of MooTools to be more stable and for future development to focus more on additional functionality and a little less refactoring of the core (which is where all the compatibility problems tend to come from). As far as charging for MooTools, that will never happen. This is an open source project and it will continue to be. My last point will be to suggest that you try and apply the MooTools class-based approach to your work more. If you use classes for nearly everything you'll find that not only is your work more reusable, it's more manageable when it's time to refactor it. I've written more about this here: http://clientside.cnet.com/best-practices/jquery-and-the-ajax-experience-programming-to-the-pattern-and-what-really-makes-one-framework-different-from-another/ http://clientside.cnet.com/best-practices/jquery-and-the-ajax-experience-programming-to-the-pattern-and-what-really-makes-one-framework-different-from-another/ and here http://clientside.cnet.com/best-practices/thoughts-on-coding-and-new-classes-as-a-result/ http://clientside.cnet.com/best-practices/thoughts-on-coding-and-new-classes-as-a-result/ gregoryt wrote: > > > i've been watching this back-and-forth for over a week now.. if you > spent as much time writing code as you did bitching about the mootools > team you would probably have everything you need by now... > > i simply cannot agree that the change to mootools 1.2 screwed anybody > over. I have converted most of the classes my company had written in > mootools 1.11 to mootools 1.2 and it wasn't that huge of a thing, it > was like maybe three small items per class. > > you seem like a smart business man, and it appears you have found a > potential market.. why not provide the support you are requesting. not > sure how anyone would expect the 8 people who contribute to the core > library capable of doing that and writing all the code and having full > time jobs... > > -gregory > > On Oct 6, 6:39 am, MX3Design <[EMAIL PROTECTED]> wrote: >> For those of you that have followed recent threads I would like to >> clearly state that I recognise the amount of effort, energy and hard >> work that has gone into MT development and for the record I've stated >> this before both in the old forums and in this usergroup... >> >> From my perspective when 1.2 was released it was so disappointing. I >> had written many scripts in previous versions and developed complete >> applications based upon the framework. To suddenly find that all of >> this code would have to be rewritten in order to use the new build was >> a complete shock. It meant that my business could no longer continue >> to use MT as it's was simply not commercially viable to update and >> redevelop countless sites and scripts. (and no the backward >> compatibility layer didn't work!) >> >> There seems to be an unofficial consensus of opinion that many MT >> users are no more than 'script kiddies' looking for a quick cut & >> paste snippet. Whilst to some extent this may be the case there is >> also a large body of professional designers and developers who rely >> heavily upon pre-coding or outsourced development. Think about what >> knowledge the average designer needs: xhtml, xml, javascript, php, >> mySQL, actionscript, css etc etc it is very difficult to be an expert >> in all these fields and find time to develop which is why a framework >> provides such a useful platform, which brings me on to my main point. >> >> There must be a huge market for a framework which would simplify and >> give designers an easy method to integrate functions into their web >> applications. A framework which provides well documented examples, and >> one which makes it ridiculously easy to use. A framework which >> provides a high level of support and one which is helpful and >> welcoming. There's no shame in providing what people need, you're not >> going to lose face, quite the opposite. In my experience people really >> appreciate help, especially when they're approaching a new area of >> knowledge, we all started at the same place but it's all too easy to >> forget that. >> >> Why not charge a licence fee and give people what they both need and >> want? I would certainly pay (provided there was backward >> compatibility!) The business model that EllisLabs and in particular >> Expression Engine have adopted works extremely well, they provide a >> good product, a user forum with excellent support, a repository and >> good documentation. Their users provide plugins, extensions and >> support to each other, it's a happy, helpful and unified community and >> the developers are making money... > > ----- The MooTools Tutorial: http://www.mootorial.com www.mootorial.com CNET Clientside: http://clientside.cnet.com clientside.cnet.com -- View this message in context: http://n2.nabble.com/Mootools-the-future%2C-a-suggestion...-tp1300547p1301450.html Sent from the MooTools Users mailing list archive at Nabble.com.
