HTMLHelper Property
Po
set of assetPackages, and then override only some of those
assetPackages in an application which <includes> that default
htmlhelper property. It replaces that entire default htmlhelper
property.
If I have a bunch of applications that all share the same
assetPackages, but in some cases need to use some custom ones, I
wouldn't want to have to duplicate that entire htmlhelper property
just to change 1 or 2 assetPackages.
Wouldn't it be more useful to append/override the new htmlhelper
property to the default one? Or at least give the option (maybe with
an attribute) to choose how you want it to behave?
Peter J. Farrell
AppManager (base app and per module). Overriding starts getting hard
because there is a lot of play in what should be overrided and what
should not. Your situation is rather unique so as you might figure it
gets harder for us to ship integration stuff like this when things get
tricky like this.
How do you feel about being able to programmatically being able to add
in (and override) asset packages via a method call? You could easily
write a simple property that does this in configure() method:
<cfset getProperty("htmlHelper").addAssetPackage("nameOfPackage",
structOfConfiguration, overrideBoolean) />
The structOfConfiguration you would of course define in XML and it would
look just exactly like when you define assets in the Html Helper
directly. Right now you can't do this, but I wouldn't be apposed to
improving the API.
Feel free to file an enhancement ticket if you think programmatic access
is ok:
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/newticket
Po said the following on 10/03/10 14:06:
Po
go ahead and write the ticket, I have a couple of questions:
1. Just to make sure, do you mean that the structOfConfiguration be
written as a regular property and then referenced by
getProperty("assetPackages")?
For example:
<properties>
<property name="assetPackages">
<struct>
<key name="assetName1">
<array>
<element value="..." />
<element value="..." />
<element value="..." />
</array>
</key>
<key name="assetName2">
<array>
<element value="..." />
<element value="..." />
<element value="..." />
</array>
</key>
</struct>
</property>
</properties>
Then add the assetPackage as follows:
<cfset getProperty("htmlHelper").addAssetPackage("assetName1",
getProperty("assetPackages"), true) />
Is this correct?
2. This might be a question for a new thread, but here it goes
anyway:
What if we want to add an assetPackage that is environment
dependent? Would this no longer be considered an asset because it is
outside of the site's root?
If it is in fact still considered an asset, would it be possible
to add the structOfConfiguration to the environment property as
follows:
<properties>
<property name="environment"
type="MachII.properties.EnvironmentProperty">
<parameters>
<parameter name="dev">
<struct>
<key name="environmentGroup" value="development" />
<key name="servers">
<array>
<element value="dev*" />
</array>
</key>
<key name="properties">
<struct>
<key name="assetPackages">
<struct>
<key name="assetName1">
<array>
<element value="..." />
<element value="..." />
<element value="..." />
</array>
</key>
<key name="assetName2">
<array>
<element value="..." />
<element value="..." />
<element value="..." />
</array>
</key>
</struct>
</key>
</struct>
</key>
</parameter>
</parameters>
</property>
</properties>
and then calling the method in the same way as above?
3. I know that this might require extra modification, but could this
method call also be exposed via the <view> tag?
Thank you for all your help.
Peter J. Farrell
Po said the following on 11/03/10 13:10:
> I do think that this enhancement would be very useful. But before I
> go ahead and write the ticket, I have a couple of questions:
>
> 1. Just to make sure, do you mean that the structOfConfiguration be
I was thinking of this:
<property name="assetPackageLoader" type="
MachII.properties.HtmlHelperAssetConfigProperty">
<parameters>
<parameter name="assetPackages">
<struct>
<key name="assetName1">
<array>
<element value="..." />
<element value="..." />
<element value="..." />
</array>
</key>
<key name="assetName2">
<array>
<element value="..." />
<element value="..." />
<element value="..." />
</array>
</key>
</struct>
</parameter>
</parameters>
</property>
This would load these asset packages into an already existing HtmlHelper
via an API. I'm not a fan of ad-hoc properties -- I'm more in favor of
a real asset package loader to load into an already existing HtmlHelper.
> Then add the assetPackage as follows:
> <cfset getProperty("htmlHelper").addAssetPackage("assetName1",
> getProperty("assetPackages"), true) />
>
>
The loader would do the API calls for you unless you wanted to build
your own stuff.
> 2. This might be a question for a new thread, but here it goes
> anyway:
> What if we want to add an assetPackage that is environment
> dependent? Would this no longer be considered an asset because it is
> outside of the site's root?
>
Yea, that is possible already using the ${} placeholders provided that
the environment property is configured before hand (properties are
loaded and configured in the order they are defined -- base XML and then
includes in order defined). This is using your Environment configuration
example that you had in your previous email.
<property name="html" type="HtmlHelperProperty">
<parameters>
<parameter name="assetPackages=" value="${properties.assetPackages}"/>
... other parameters ...
</parameters>
</property>
I'm not sure what you mean by an asset output of the site's root. I
think it's a safe to assume that all assets have to be accessible via a
client browser. I don't think location of the asset has anything to do
with whether it can be considered an asset.
> 3. I know that this might require extra modification, but could this
> method call also be exposed via the<view> tag?
>
I'm not sure what you mean here. If you are referring to adding
additional asset packages, I wouldn't think that view custom tags is the
appropriate place to do that since custom tags are for view output not
configuration.
Po
> via an API. I'm not a fan of ad-hoc properties -- I'm more in favor of
> a real asset package loader to load into an already existing HtmlHelper
I completely agree. I just wasn't sure if this is what you meant.
This makes it much easier and more standardized.
This being said, the rest of it makes a lot more sense now.
> I'm not sure what you mean here. If you are referring to adding
> additional asset packages, I wouldn't think that view custom tags is the
> appropriate place to do that since custom tags are for view output not
> configuration
I originally thought you expected the user to programmatically access
the method call, just like regular addAssetPackage calls (as opposed
to calling it directly in the configure() method as you mentioned).
So I thought we would override assetPackages per view, which didn't
make as much sense as what you described now.
That is why I asked if it would also be accessible via the view tag,
which in this new context obviously makes no sense.
> Yea, that is possible already using the ${} placeholders provided that
> the environment property is configured before hand (properties are
> loaded and configured in the order they are defined -- base XML and then
> includes in order defined).
I had tried this but apparently I had the wrong configuration in the
environment property. I was trying to use the ${} placeholder in the
element tag, setting them one by one, as opposed to using them in the
parameter tag setting the whole structure in one shot.
At least I'm glad my hunch was right.
> I'm not sure what you mean by an asset output of the site's root. I
> think it's a safe to assume that all assets have to be accessible via a
> client browser. I don't think location of the asset has anything to do
> with whether it can be considered an asset
When I say the "site's root", I mean the web root of the site.
Since i could not get the environment to play nice with the htmlhelper
property originally, it seemed that assets were always bound to be
site specific.
This being the case, it seemed that you had constrained assets as an
entity only available via the site's web root (i.e site's root).
But now that I got it to work with the way you described I see that
this is not the case.
Now that I seem to fully understand I shall go ahead and file the
ticket.
Thanks for all the help and one hell of an amazing framework!
Peter J. Farrell
Po said the following on 12/03/10 12:15:
>> This would load these asset packages into an already existing HtmlHelper
>> via an API. I'm not a fan of ad-hoc properties -- I'm more in favor of
>> a real asset package loader to load into an already existing HtmlHelper
>>
> I completely agree. I just wasn't sure if this is what you meant.
> This makes it much easier and more standardized.
> This being said, the rest of it makes a lot more sense now.
>
>
Good. Glad we are on the same page.
>> I'm not sure what you mean here. If you are referring to adding
>> additional asset packages, I wouldn't think that view custom tags is the
>> appropriate place to do that since custom tags are for view output not
>> configuration
>>
> I originally thought you expected the user to programmatically access
> the method call, just like regular addAssetPackage calls (as opposed
> to calling it directly in the configure() method as you mentioned).
> So I thought we would override assetPackages per view, which didn't
> make as much sense as what you described now.
>
Basically, we want to have all the overriding done and completed when
the framework loads. Any other complex assets that vary on any variety
of factors could easily be mock by using:
<view:script href="file1custom,file2custom,file3common"/>
Since the view:script tag can take a list of assets to include.
> That is why I asked if it would also be accessible via the view tag,
> which in this new context obviously makes no sense.
>
>
>> Yea, that is possible already using the ${} placeholders provided that
>> the environment property is configured before hand (properties are
>> loaded and configured in the order they are defined -- base XML and then
>> includes in order defined).
>>
> I had tried this but apparently I had the wrong configuration in the
> environment property. I was trying to use the ${} placeholder in the
> element tag, setting them one by one, as opposed to using them in the
> parameter tag setting the whole structure in one shot.
> At least I'm glad my hunch was right.
>
Bindable property placeholders only work at base <parameter> levels.
Anything nested deeply are not evaluated on framework load events. The
only exception is the Logging/Caching properties where we do some some
additional resolution more deeply nested data. This by property loader
and the html helper doesn't go any deeper.
>> I'm not sure what you mean by an asset output of the site's root. I
>> think it's a safe to assume that all assets have to be accessible via a
>> client browser. I don't think location of the asset has anything to do
>> with whether it can be considered an asset
>>
> When I say the "site's root", I mean the web root of the site.
> Since i could not get the environment to play nice with the htmlhelper
> property originally, it seemed that assets were always bound to be
> site specific.
> This being the case, it seemed that you had constrained assets as an
> entity only available via the site's web root (i.e site's root).
> But now that I got it to work with the way you described I see that
> this is not the case.
>
Good. If you have time, I'd appreciate it if you could add a section in
the Html Helper Property on the wiki for this kind of advanced stuff
you've done. I think it would be great addition to the wiki and a great
way to share your knowledge with the rest of the community. People who
add to our documentation are always top dollar in my book.
> Now that I seem to fully understand I shall go ahead and file the
> ticket.
>
I'll be looking for it and I'll discuss it with the team to see exactly
how we will address this deficiency so things can be made easier.
> Thanks for all the help and one hell of an amazing framework!
>
I'm glad you like Mach-II. It's definitely a labor of love for us on
the team and a lot of time and energy has been spent on it. This coming
June marks five years of me being lead developer of the framework! I am
extremely happy and thankful to had people join Team Mach-II in the past
couple of years. We definitely are able to make great progress.
Best,
.Peter