Mark Ramm wrote: > Sorry Ablerto, > > I think that post came out of left field for you, and I didn't express > myself very well. I don't want to denigrate rum in any way. I've > used it in apps at work already and love it. > > What I wanted in the TG2 release was a form generation library. > Ultimately I also wanted an admin interface too, but a newforms > competitor was at the top of my list for this release. > > As chirs mentions we both tried to make rum work as a form generation > tool, but it was somewhat difficult, (all the rum form generation > stuff required lots of request context stuff to be setup and torn > down). > > Rum has lots of potential, but it's a mini-framework that creates a > wsgi app, and not a library of form generation tools. And that > design decision makes tighter integration with a TurboGears app > harder. Of course it's easy to mount a RUM app in TG2, and we will > always support and document that. > > But in my mind integration of admin stuff that can compete with the > new django admin requires a bit more flexibility in embedding forms > and whatnot in pages with content generated by the main app. Sprox > provides both, but what I really care about in terms of shipping with > TG2 is the form generation library stuff. > > So, you're right. Rum is not a form generation library. And that's > why we're including sprox. > > Sprox also happens to implement an admin generator thing, but on that > front Rum is still ahead of Sprox. And that's definitely not why I > agreed to let chris put sprox in the index. > > It's possible that Rum could be refactored a bit so that the form > generation stuff was exposed more cleanly. But I wasn't up to the > task with the other stuff on my plate. And, even then I'd like to > support jython/ironpython with all the stuff in the TG core, and that > will be difficult while using peak-rules because they have different > byte-code systems, and ByteCodeAssembler would have to be modified to > help them, and that's a task that's definitely over my head. >
Fair enough. I more or less (more "more" than "less") agree with all your points and see the motivation behind them. As I've said in this same thread (in rum-discuss), Rum isn't really in the business of automatic form generation and I would have gladly "outsourced" this part of it if there was a *model-based* (vs. "table-based" which is what DBsprockets was at the time Rum was being coded) and TW based alternative I could re-use, but there wasn't. Fortunately there's now an alternative and I will surely evaluate if Rum can reuse this component to shrink its code-base and support costs. However, my main gripe and, in retrospect, the reason for my overreaction, is that these good points you've made weren't discussed publicly before. If this is what the TG lead has privately decided I'll go with it. Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
