Changing generatedViewMapping for scaffolds

[Bob Silverberg]

I want my generated view files to be written to views/generated, so I changed my Coldspring.xml file like so:

<property name="generatedViewMapping"><value>views/generated</value></property>

This works for the writing of files: they do get written to that location. However, when I try to run a scaffolded event, MG cannot find my view files.  I get a message like:

The template (List.Province.cfm) was not found in any registered view mappings (/views).             

OK, so I manually added /views/generated to my view mappings in my Coldspring.xml like so:

<property name="viewMappings"><value>/views,/views/generated</value></property>

and now it's all working as expected.

However, the documentation at http://docs.model-glue.com/wiki/HowTos/HowToUseScaffolds/CustomizingGeneratedCfml#Scaffolds:CustomizingGeneratedCFML seems to suggest that I should not have to manually add that folder to my viewMappings. It says:

"Scaffold tags cause certain files to be generated, such as lists, views, and edit forms. This generated code is placed into a directory governed by the ScaffoldPath property of the ModelGlueConfigurationBean in ColdSpring.xml.

Advanced note: The value of this setting is appended to the ViewMappings setting, making this directory the last-searched directory when an include tag is encountered."

Now that statement is already inaccurate (I believe) as it is the generatedViewMapping setting, not the scaffoldPath setting that determines where the files will be written, but the note following it does seem to suggest that the path I specify will be added to the viewMappings automatically.

So, is this a bug, or just a misunderstanding on my part?  And if the latter, does it still seem like a good feature to add?

Cheers,

Bob

-- 

Bob Silverberg
www.silverwareconsulting.com

[denstar]

It's a bug. :)

--
Every discourse, even a poetic or oracular sentence, carries with it a
system of rules for producing analogous things and thus an outline of
methodology.
Jacques Derrida

> --
> Model-Glue Sites:
> Home Page: http://www.model-glue.com
> Documentation: http://docs.model-glue.com
> Bug Tracker: http://bugs.model-glue.com
> Blog: http://www.model-glue.com/blog
>
> You received this message because you are subscribed to the Google
> Groups "model-glue" group.
> To post to this group, send email to model...@googlegroups.com
> To unsubscribe from this group, send email to
> model-glue+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/model-glue?hl=en
>

[Dennis Clark]

It worked in MG2, but does not work in the latest MG3 release.

I just filed an issue for it: http://trac.model-glue.com/ticket/376

FWIW I added "backwards-compatibility" as an issue keyword. I set the severity to "normal" since there is a known workaround, but I feel this ought to be fixed quickly.

Cheers,

-- 

Dennis 

[Bob Silverberg]

Here's a patch:

Index: ModelGlueConfiguration.cfc

===================================================================

--- ModelGlueConfiguration.cfc (revision 64)

+++ ModelGlueConfiguration.cfc (working copy)

@@ -152,6 +152,9 @@

 <cffunction name="setGeneratedViewMapping" returntype="void" output="false" access="public">

  <cfargument name="GeneratedViewMapping" type="string" />

  <cfset variables._instance.GeneratedViewMapping = arguments.GeneratedViewMapping />

+ <cfif listFind(arrayToList(variables._instance.ViewMappings),arguments.GeneratedViewMapping) eq 0>

+ <cfset arrayAppend(variables._instance.ViewMappings, arguments.GeneratedViewMapping) />

+ </cfif>

 </cffunction>

 <cffunction name="getGeneratedViewMapping" returntype="string" output="false">

  <cfreturn variables._instance.GeneratedViewMapping />

I'm using ArrayToList() which isn't very efficient, and could be replaced my using the underlying Java array's methods, but I figured that this code is going to run once, at init, and this array will never be very large.  The patch works as is, but feel free to tweak it if you like.

Cheers,

Bob

Bob Silverberg
www.silverwareconsulting.com

[Bob Silverberg]

I added my patch to the Trac ticket as well.  I'm not sure what process you'd like us to follow for patches.

Cheers,

Bob

--
Bob Silverberg
www.silverwareconsulting.com

[Dennis Clark]

Darn it Bob, if I had known you were going to include the patch on Trac I would have told you sooner that your patch is only 50% correct.

Your patch assumes that ColdSpring will set the ViewMappings property before the GeneratedViewMapping property, yet ColdSpring doesn't guarantee this.  If the patch works for you it is only doing so coincidentally.

I don't see a particularly elegant way to address the bug, but a simple and safe way is to combine the values on the getInstance() method, like this:

<cffunction name="getInstance" returntype="struct" output="false">

<cfset var instance = structCopy(variables._instance) />

<!--- Append the generated view mapping to the normal view mappings --->

<cfset instance.viewMappings = ListAppend(instance.viewMappings,instance.generatedViewMapping) /> 

<cfreturn instance />

</cffunction>

BTW I'm not concerned about generatedViewMapping already being in viewMappings, as ModelGlue searches for views in order and the generatedViewMapping is added to the end of this list. This means that the only time ModelGlue will search the last path for a view is when the view was not found in any of the previous paths, and if the last path is a duplicate than the view is guaranteed to not be there (and therefore result in an error).

Cheers,

Dennis

[Bob Silverberg]

It was just a best-guess at what to do.  I did actually think about the fact that the order that the setters were called might mess things up, so thanks for catching that. What I tend to do in situations like that is to have a method that gets called after Coldspring is done injecting dependencies which does setup that assumes that all injection is already done. That might result in a more "elegant" solution, although I'm not sure if it fits in with how MG is currently architected.