RoR and Zope3
i'm not really sure how to feel about this.
i REALLY like ruby on rails. this is difficult for me to come to terms with immediately. i love python. and, at least from my first taste of ruby, i'll probably always like python's syntax better. python taught me to program, not just script. but i guess we'll see as i use ruby more. the frustrating thing is that i love python, and i love zope3. theoretically.
i've spent a lot of time with zope3. at least 6 months or more, i don't really remember now. i admit, i was new to adapter/interface oriented design when i started with zope3, so a lot of the "why's" and "how's" of the framework took me some time to get into. then there's the learning curve of zcml and tales, and the magic of adapter registry and default views and all sorts of things. Stephan Richter and Phillip VW's books were/are both excellent, and got me through the initial trials and tribulations.
but i guess what i've been feeling lately is that i'm fighting with the framework as much as i'm developing in it. core things that i feel are indispensable from modern web frameworks, like simple ajax support and simple rdb integration, just aren't there. you can roll your own certainly, zope3 is nothing if not extensible, but i'm often left with the question of "what's the right way to do this? what's the right design pattern to use here?"
my trouble with zope3 is not how powerful it is. it's extremely powerful. my trouble with zope3 is getting at that power. a lot of things that i want to just be simple, aren't. i wanted to build my own login form with a few other parameters and i had to develop my own PAU just to do it the way i wanted to. and i understand my requirements were a bit picky on what needed to happen, but it just took so long to fight with it...
and i'm not talking about whether or not i'm too lazy to write my own way around these problems, i'm talking about whether or not i have time to roll my own, given the deadlines i'm working with. and whether i have time to go back and change an interface, a class, zcml, and potentially have to use generations code, every time the requirements change a little, or we want to capture a new bit of data, or move a piece of trackable data from one class to another.
ruby on rails' ability to be data-determined from the start in effect forces the framework to be adaptable to changes, since most of what it's displaying is data driven anyway.
and i think a lot of the blame is to be shifted back on to me. zope3 is, for better or worse, a CMS at it's core. and for the first few applications i needed to build in it, that was more than ok. i needed to implement a lot of functionality that would expose to a user the ability to create and manage content objects, and pass that content back and forth. i learned a lot, not just about zope3, but about programming in general. zope3 made me a better programmer.
but now i want it to be a web framework that can simply and efficiently do more than just content management, and i think i may be trying to use the wrong tool for the job.
i can see a lot of places where ruby on rails can't/won't be able to compete with zope3. but i can see a lot of places where it can both compete, and win.
i don't know. i'm scheduled for the may8-11th zope3 training with stephan, and i hope to be able to maybe see the pieces i'm missing with zope3. because right now i feel like zope3 is the best tool for the job for complex content management dealing with a large user bases. but i don't see it as the right tool for agile (both the methodology and in a more visceral sense) development and the ability to quickly adapt to refined/redesigned requirements.
i haven't come to a real conclusion in my thoughts on this. i still love zope3. but i'm disenchanted with it, the honeymoon is over. it has weak points. i know the hardcore dev guys can easily brush that off as my lack of skill or requisite knowledge. but i'm a smart guy, and i figure stuff out pretty quick, without much help usually, and there are things that are just downright difficult to do in zope3 that should be easier.
i guess though, my frustration may be that zope3 is fairly bleeding edge tech. the real frustration is that there just aren't plugins for a lot of things that i'd like. i'd like to be able to download "jsonform" or something that has the same render/update patterns as formlib, and just let it work. i'd like for zope3 to have an orm that works like sqlalchemy integrated at the transaction level. i know there's a project for this, and they have my impressed applause, but it just seems to me that ORM mapping should be so core to the framework as to be a utility, just like a PAU or something similar, where interfaces are registered to an rdb, and that's the last time the developer has to think about it.
i want there to be one standard way to create forms, no magic auto form generation that confuses the issue. the ruby strategy of simplicity based on convention rather than configuration is something that should be seriously considered. the long running thread of "zcml should do less" that went on a while ago highlights this.
i want modification of my interfaces and objects to be gracefully handled by the architechture, rather than having it croak if i change a TextLine to a PersistentList in some utility. if an object in the db no longer conforms to the interface, flag it and deprecate it out of being loaded, and warn to the log or console that the object no longer conforms and needs to be updated.
i've probably ranted too much now. i don't have the skill level to make any of that happen. but i want to keep using zope3 for more than just my CMS needs. i believe it is, at its core, a more extensible, powerful set of technology than ruby on rails. but ruby on rails is data driven, and agile, and most of all, simple to get going very fast with. i've spent a lot of time, energy, and money on zope3, and i feel like i can say without feeling out of line that it is not any of those things. like a cliff face it is imposing and powerful and unassailably potent. and learning how to make it do what you want is like climbing that same cliff face.
the choice for me, and i think a lot of developers, is not "what solves the problem most elegantly?" but "what solves the problem NOW, and lets me solve the evolving problems as they emerge, with the least downtime, the least overhead, and the least frustration?"
argh. i'm going to bed.
i REALLY like ruby on rails. this is difficult for me to come to terms with immediately. i love python. and, at least from my first taste of ruby, i'll probably always like python's syntax better. python taught me to program, not just script. but i guess we'll see as i use ruby more. the frustrating thing is that i love python, and i love zope3. theoretically.
i've spent a lot of time with zope3. at least 6 months or more, i don't really remember now. i admit, i was new to adapter/interface oriented design when i started with zope3, so a lot of the "why's" and "how's" of the framework took me some time to get into. then there's the learning curve of zcml and tales, and the magic of adapter registry and default views and all sorts of things. Stephan Richter and Phillip VW's books were/are both excellent, and got me through the initial trials and tribulations.
but i guess what i've been feeling lately is that i'm fighting with the framework as much as i'm developing in it. core things that i feel are indispensable from modern web frameworks, like simple ajax support and simple rdb integration, just aren't there. you can roll your own certainly, zope3 is nothing if not extensible, but i'm often left with the question of "what's the right way to do this? what's the right design pattern to use here?"
my trouble with zope3 is not how powerful it is. it's extremely powerful. my trouble with zope3 is getting at that power. a lot of things that i want to just be simple, aren't. i wanted to build my own login form with a few other parameters and i had to develop my own PAU just to do it the way i wanted to. and i understand my requirements were a bit picky on what needed to happen, but it just took so long to fight with it...
and i'm not talking about whether or not i'm too lazy to write my own way around these problems, i'm talking about whether or not i have time to roll my own, given the deadlines i'm working with. and whether i have time to go back and change an interface, a class, zcml, and potentially have to use generations code, every time the requirements change a little, or we want to capture a new bit of data, or move a piece of trackable data from one class to another.
ruby on rails' ability to be data-determined from the start in effect forces the framework to be adaptable to changes, since most of what it's displaying is data driven anyway.
and i think a lot of the blame is to be shifted back on to me. zope3 is, for better or worse, a CMS at it's core. and for the first few applications i needed to build in it, that was more than ok. i needed to implement a lot of functionality that would expose to a user the ability to create and manage content objects, and pass that content back and forth. i learned a lot, not just about zope3, but about programming in general. zope3 made me a better programmer.
but now i want it to be a web framework that can simply and efficiently do more than just content management, and i think i may be trying to use the wrong tool for the job.
i can see a lot of places where ruby on rails can't/won't be able to compete with zope3. but i can see a lot of places where it can both compete, and win.
i don't know. i'm scheduled for the may8-11th zope3 training with stephan, and i hope to be able to maybe see the pieces i'm missing with zope3. because right now i feel like zope3 is the best tool for the job for complex content management dealing with a large user bases. but i don't see it as the right tool for agile (both the methodology and in a more visceral sense) development and the ability to quickly adapt to refined/redesigned requirements.
i haven't come to a real conclusion in my thoughts on this. i still love zope3. but i'm disenchanted with it, the honeymoon is over. it has weak points. i know the hardcore dev guys can easily brush that off as my lack of skill or requisite knowledge. but i'm a smart guy, and i figure stuff out pretty quick, without much help usually, and there are things that are just downright difficult to do in zope3 that should be easier.
i guess though, my frustration may be that zope3 is fairly bleeding edge tech. the real frustration is that there just aren't plugins for a lot of things that i'd like. i'd like to be able to download "jsonform" or something that has the same render/update patterns as formlib, and just let it work. i'd like for zope3 to have an orm that works like sqlalchemy integrated at the transaction level. i know there's a project for this, and they have my impressed applause, but it just seems to me that ORM mapping should be so core to the framework as to be a utility, just like a PAU or something similar, where interfaces are registered to an rdb, and that's the last time the developer has to think about it.
i want there to be one standard way to create forms, no magic auto form generation that confuses the issue. the ruby strategy of simplicity based on convention rather than configuration is something that should be seriously considered. the long running thread of "zcml should do less" that went on a while ago highlights this.
i want modification of my interfaces and objects to be gracefully handled by the architechture, rather than having it croak if i change a TextLine to a PersistentList in some utility. if an object in the db no longer conforms to the interface, flag it and deprecate it out of being loaded, and warn to the log or console that the object no longer conforms and needs to be updated.
i've probably ranted too much now. i don't have the skill level to make any of that happen. but i want to keep using zope3 for more than just my CMS needs. i believe it is, at its core, a more extensible, powerful set of technology than ruby on rails. but ruby on rails is data driven, and agile, and most of all, simple to get going very fast with. i've spent a lot of time, energy, and money on zope3, and i feel like i can say without feeling out of line that it is not any of those things. like a cliff face it is imposing and powerful and unassailably potent. and learning how to make it do what you want is like climbing that same cliff face.
the choice for me, and i think a lot of developers, is not "what solves the problem most elegantly?" but "what solves the problem NOW, and lets me solve the evolving problems as they emerge, with the least downtime, the least overhead, and the least frustration?"
argh. i'm going to bed.
posted by baldtrol at 2:36 AM
0 Comments:
Post a Comment
<< Home