front_site.dryml vs application.dryml

[Bryan Larsen]

On Tue, Apr 17, 2012 at 7:15 PM, Bob Sleys <bsl...@gmail.com> 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

[Bob Sleys]

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

[Bryan Larsen]

No, you were right. I misread your original email.

Hobo 1.4.0.pre4 loads application.dryml and then everything in
app/views/taglibs/application/*.dryml and then front_site.dryml

Hobo 1.4.0.pre5 never automatically loads
app/views/taglibs/application/*.dryml. It only loads a single file
automatically: X_site.dryml preferentially, with application.dryml as
a fallback.

You can get the old behaviour back by adding

<include src="application"/>
<include src="application/*"/>

to the top of your front_site.dryml

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 hobo...@googlegroups.com.
> To unsubscribe from this group, send email to
> hobousers+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hobousers?hl=en.