On Nov 5, 2010, at 10:57 AM, Peter Ehrlich wrote: > and there it is. Order code form, hidden and forgotten in > application.dryml. resolved. > > I still don't really think that this is really because of something I > did wrong or should not have forgotten. Unfortunately this is > building a very foreboding feeling I have when working with .dryml - > some of the modularization and general form just doesn't seem to make > sense. Why are viewhints, which are benign and simple at best, given > individual files for every model
Viewhints are split out that way because otherwise the Rails autoloader will has a sad. (matching classnames to filenames) > while tag extensions, which can be a > multitude of complex unorganized unrelated blocks of code, jammed in > to a single file? A file that, when its incorrect, generates > absolutely no useful error data, to boot. > Yep - DRYML stacktraces suck most mightly. The only way I've ever managed to get anything useful out of them is by ignoring all the generated _tag_context/new_context/etc noise and instead looking for files I've got control over. In this case, about a hundred lines down (ugh) one discovers: app/views/taglibs/application.dryml:17:in `form__for_order' Which is what would have helped track the issue down. I'd also add a +1 for Domizio's suggestion - pretty much any time I get an 'undefined *foo*' error I immediately reach for the "Search In Project" button on Textmate. Picked that habit up working on an app with models named things like 'CertificationRequirement', which gets spelled wrong in a remarkable number of ways while coding on too little sleep... :) BTW, can you check which specific version of RVM you're running? That backtrace should have been a lot cleaner, as there's code in Rails 2.3.x to "clean" backtraces to show files sourced from inside gems with the gem name + version instead of a giant path blob. It appears to be malfunctioning. > Actually, that doesn't matter. I only have one question, and that is: > how do I go about changing this? > That's a good question. Unlike the rest of Rails, there's not really a good way to "autoload" taglibs, apart from the basic functionality involved in subsites. It's basically back to the old days where file structure was arbitrary and glued together with #includes (or in this case <include>s). I'd be glad to hear any suggestions or even just practices that others on this list have to manage the mess. Thanks, --Matt Jones -- You received this message because you are subscribed to the Google Groups "Hobo Users" 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/hobousers?hl=en.
