RE: [Reactor For CF] Reactor R&D

[Shannon Jackson]

Bingo!  Sorry, I see how that could have been confusing.  Yes, it is calling embedded beans that hurts: myBean.getMyRealatedBeanRecord()  -- myBean.getMyRelatedBean().   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Rypka-Hauer Sent: Friday, March 24, 2006 10:26 AM To: reactor@doughughes.net Subject: Re: [Reactor For CF] Reactor R&D   Thanks for the reply Shannon...   I just realized something that's been puzzling me but couldn't figure out what or why... when you say "bean name" you actually mean "getter method name," right? Because it's not the name of the bean that matters but the getSomeRecord() vs getSome() that is at issue...   This difference may lead to a breakdown in communication because having a "bean naming convention" and having an "API naming convention for our beans" are to very very different things. I think my brain is starting to absorb a little of your perspective... I'll get back to you in a while when I've absorbed a bit more. :)   Laterz, J   ------------------------------------------------ Jared C. Rypka-Hauer Continuum Media Group LLC http://www.web-relevant.com Member, Team Macromedia - ColdFusion   "That which does not kill me makes me stranger." - Yonah Schmeidler   On Mar 24, 2006, at 10:09 AM, Shannon Jackson wrote: Hi Jared,   Great points.      >You have to keep in mind that if 95% of the people who use Reactor don't need or wouldn't use the feature you've suggested, then you've just added complexity, learning curve, likely errors, extra weight to the classes and, ultimately, extra work for every single one of them.   I agree with this; however, I was thinking that making the bean names more malleable might increase the margin of developers using it.  It would potentially remove a painful barrier migrating applications and integrating Reactor with other patterns. So, I do completely agree with your philosophy but I am using it as an argument in favor.   > Why can't you (or won't you) just add a getN() method that wraps the getNRecord() method yourselves? If you're customizing any of the objects they you don't have a pristine API to your record objects anyway... why is this option not acceptable?   It is acceptable—again, we just raised the issue after a lot of R&D because we noticed how close it was already.  Figured it would be a legit discussion.   -          Shannon   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jared Rypka-Hauer Sent: Friday, March 24, 2006 9:53 AM To: reactor@doughughes.net Subject: Re: [Reactor For CF] Reactor R&D   I'd like to point out that, regardless of the language or framework, this kind of thread can often feel awfully "hot" to people, especially when you're offering an idea that you think is both simple and important and you're not getting the kind of hop-to-it enthusiasm you were hoping for. " While you're excited and enthusiastic, other people will evaluate your suggestion with less enthusiasm and more "critique" than, as the contributor, the original suggestor... even if you've done your homework and tried to validate the idea ahead of time.   It's assumable that, since someone made the suggestion, they think it's a good idea and has merit. That's never (or almost never) in question. And I think that this idea is, unlike many others I've seen suggested to framework makers in the past, actually relevant and appropriate to the framework at hand (as opposed to something like "can we add AJAX to Model-Glue?" which was actually brought up on the MG list!) What's in question is how much work is involved in making it happen, how much gain it so be had by doing so, and how many users of the framework will actually benefit from it. The edge cases (which seems to be what you guys are dealing with) often don't make it in to the final cut because: 1) they don't benefit a broad enough base to make it worthwhile and 2) because the audience for the feature is limited, the result is extraneous feature sets for the mainstay of people who use the framework.   This is probably going to be misunderstood, but I'm going to say it anyway... just don't read any tone or inflection into it. I'm not casting aspersions or anything of the kind... just read the words:   You have to keep in mind that if 95% of the people who use Reactor don't need or wouldn't use the feature you've suggested, then you've just added complexity, learning curve, likely errors, extra weight to the classes and, ultimately, extra work for every single one of them. The presented rationale behind this potential sacrifice on their part is "so we can abide by Java bean naming conventions" and "then Reactor will be a very easy drop-in ORM replacement for other things we use/have used/might use." Compared to making the lives of 95% of users more difficult, making your life easier may or may not be worth it. Even if it would drastically, dramatically, incredibly improve things for you, as bad as that sounds, telling the other 95% of users to get stuffed because it'll help you is not in any way in the best interests of the tool.   There are a few questions I have, though... the answers may have already been scattered thru the thread, but I'd like to see the answers in one place if you don't mind:   Why can't you (or won't you) just add a getN() method that wraps the getNRecord() method yourselves? If you're customizing any of the objects they you don't have a pristine API to your record objects anyway... why is this option not acceptable?   Since you have to tweak your DAOs to make any new ORM framework fit, why not just tweak for Reactor too?   I suspect the likely answer is "because the way Reactor works now isn't how Java works." Bummer. This one annoys me. :) Reactor's API is set up to differentiate between the Iterator and the Record, so, since getNRecord() and getNIterator() both exist on the objects in question you're asking to turn getNRecord() into the default and, IMO, breaks the consistency and the stability of the framework's API. If you want custom methods, create custom methods, but I don't see how breaking the API of the framwork (which is essentially what this would do) is in anyone's best interests.   I do think this request would make life a LOT easier for you guys, but, as edge cases everywhere know, that doesn't really matter (unless of course you were paying for it -- paying/sponsoring is one good way to get your wantages added real fast) if there's no widespread need for your request. The alternative is to check reactor into your own repository, alter it yourselves to do what you want, and go from there. Macromedia ran a slightly modified version of Mach-II for a long, long time... that may be an option for you guys as well.   Anyway, my infamy for writing huge emails is catching up with me and I'll gonna shut up now. I hope I've brought up good points and that I haven't pissed anyone off too badly... because I meant them as discussion points and not as slams or dissing.   Laterz, J   ------------------------------------------------ Jared C. Rypka-Hauer Continuum Media Group LLC http://www.web-relevant.com Member, Team Macromedia - ColdFusion   "That which does not kill me makes me stranger." - Yonah Schmeidler   On Mar 24, 2006, at 12:44 AM, Shannon Jackson wrote: True, but if I were to stack the benefits in order of importance (personally) I would have to say that migration is key at this point. Reactor is going to go 1.0 in the near future -- it's about building a community, right? Swapping out (with ease) is a golden concept too; but not the entire basis for the argument.   It is such a simple, little, tweak that could bring in dozens of migrated applications in our organization alone.   Never-the-less, I wish people were not so hostile to a discussion here. We mean no harm and we come in peace!   - Shannon -- Reactor for ColdFusion Mailing List -- reactor@doughughes.net -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/   -- Reactor for ColdFusion Mailing List -- reactor@doughughes.net -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/