I'm not sure if the confusion is on my part or yours. I didn't intent to imply all .dryml files are loaded, at least not in all locations. However, all .dryml files in taglibs/application are loaded or at least where in 1.3 and 1.4 prior to the latest release. I was trying to say that it's inconstant that application.dryml, auto loaded taglibs/application/*dryml, or at least they got loaded right after application.dryml but admin_site.dryml and front_site.dryml didn't have similar behaviors. If you goal is to reduce auto loading of files I'm all in favor of that.
I look forward to testing your latest release but it might not be until next week. Bob On Wednesday, April 18, 2012 10:23:42 AM UTC-4, Bryan Larsen wrote: > > On Tue, Apr 17, 2012 at 7:15 PM, Bob Sleys <[email protected]> wrote: > > I've run across similar issues with 1.4 and think I've nailed down. If > what > > I'm going to describe next doesn't help then I guess disregard it LOL. > > > > The issue at least in my case came down to loading order. > > > > First core.dryml is loaded from the gems directly - no problems here > > > > Next application.dryml is loaded but it doesn't load the auto generated > > rapid tags by default. However it does load all dryml files in > > taglibs/application automatically. > > > > Next the sub site dryml file is loaded, typically either > front_site.dryml or > > admin.dryml. This is where the auto generated rapid dryml files are > loaded > > at by default. > > > > The issue is if you try to extend any of the auto generated tags before > they > > get loaded you'll get errors. This is particularly confusing because > much > > of the documentation states to place these tag extensions in > > application.dryml but with 1.4 the auto tags haven't been loaded yet > leading > > to errors. > > That's an excellent summary of the problem. two corrections: > > - all dryml files are not loaded automatically. You can make it do > that by adding a <include src="*"/> statement, but I highly recommend > against that! However, something like <include src="common/*"/> > would be useful in some apps. > > - it's admin_site.dryml, not admin.dryml > > This isn't a new problem, Hobo 1.3 has a similar problem. The > difference is that the default generated app is slightly different. > Depending on the options you choose, front_site.dryml either doesn't > exist, or application.dryml is blank. It was easy to generate an app > without front_site.dryml but with admin_site.dryml, which meant that > the admin portion loaded both the generated files for the front site > and for the admin site. > > There are three reasons why the generator changed in 1.4: > > - Hobo 1.4 allows subsites to have different themes > > - there is a new "install_plugin" generator > > - I wanted to eliminate the support situation where a new user may or > may not have a front_site.dryml. > > And I wanted to change things in a way that broke 1.3 apps as little > as possible. > > I think it's best to change DRYML so that it doesn't load > application.dryml directly. That means that people upgrading from > 1.3 or 1.4.0.pre4 will have to add an <include src="application"/> > line to front_site.dryml and admin_site.dryml, but I think the > problems that you and others have run in to are serious enough to > warrant the breakage. > > Do any of the old-timers have any problems with this breakage? > > Bryan > > > > > The simplest fix is move your tags out of application.dryml and place > them > > either in front_site.dryml or admin.dryml. > > > > It's also quite confusing that all dryml files in taglibs/application are > > auto loaded at the same point as application.dryml but the auto generated > > files aren't which by default will typically lead to errors. > > > > IMHO the auto loading of taglibs/application should be discontinued OR > when > > front_site.dryml loads all dryml files under taglibs/front_site should > load > > AND all files in taglibs/admin_site should load when admin.dryml loads. > IE > > when a subsite loads it should load all dryml files in > > taglibs/<subsite>_site. > > > > Of course this can be achieved by adding an <include ...> into each > > subsite.dryml file to mimic the auto loading. (this is what I've done) I > > then place tags into dryml files named after the model they are for in > > the appropriate subsite_site dir so I can keep them organized. I really > do > > hate haveing too much stuff in one file and this lets me keep my tags > > organized. > > Yes, this is an excellent way of doing things. If you take a look at > the source code for RAPID in 1.4 you'll notice that we now have a > large number of small files instead of a small number of large files, > so we're moving in the same direction ourselves. > > Bryan > > -- You received this message because you are subscribed to the Google Groups "Hobo Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/hobousers/-/sAdR0YJ8hT4J. 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.
