We're going to be deploying on Solaris, but we are currently
developing on Windows so I imagine we are going to hitting these types
of issues at some point in future and I've been subconsiously reading
this process...
But the problems in the validation are not OS specific, which is
making me even more confused about why no one else is hitting the same
brick walls as us.
Mark
On 9/13/06, Angus Johnson <[EMAIL PROTECTED]> wrote:
Heh... I share your pain Mark.
I'm testing on Redhat and ran into a whole bunch of case issues myself. I
haven't hit any probs with validation yet as I have not started to build
that in yet.
Some things I'd like to point out to others who have to take care with case
sensitivity:
- project name (config.xml) is used for the directory name under
/reactor/projects
- object names (config.xml) are used to prefix objects. I started off
capitalising the object names as this is how I like to see my cfc's but this
clashed with the lowercase mysql table names. So my lower case object names
produce viewRecord.cfc (not using alias)
- when calling reactor.createRecord('view') etc the name of the object is
case sensitive
What really had me in a pickle was writing a bunch of custom gateway
functions on my windows machine without a care for case and then compiling
and deploying on red hat. Ugh!
Other than what you say about validation reactor seems to be ok with case. I
didn't come across any inconsistencies. The doco needs a section on
developing for *nix.
Angus
On 12/09/06, Mark Stanton <[EMAIL PROTECTED]> wrote:
> Hi All
>
> We've become a bit stuck in and around the case sensitivity of the
> error codes in reactor.
>
> (For the rest of this email I'm going to use a table called Agency
> with a field called Name).
>
> When we started working with reactor the generated code respected the
> case sensitity of all our object names.
>
> The
/reactor/project/projectName/validator/AgencyValidator
contained
> code such as:
>
> <cfset
arguments.ErrorCollection.addError("Agency.Name.invalidType")
/>
>
> The generated Agencydirectionary.xml file contained:
> <Agency>
> <Name>
>
> Our custom AgencyValidator.cfc contained things like:
>
> <cfset arguments.ErrorCollection.addError
("Agency.Name.isDuplicate")>
>
> ..and everything worked fine.
>
> Then came version 331
> (http://trac.reactorframework.org/reactor/changeset/331
), which makes
> all *new* entries in the dictionary get written in lower case. So *if*
> we deleted our Agencydictionary.xml and let it regenerate it would now
> have:
> <agency>
> <name>
>
> However if we didn't delete and regenerate our dictionary files we
> would end up with a double up:
> <Agency>
> <Name>...</Name>
> <name>
>
> At this point we started getting a lot of errors so I opened
> http://trac.reactorframework.org/reactor/ticket/56 and
rolled back my
> version.
>
> When nothing happened on that ticket for a week or two I looked a bit
> deeper at what was going wrong and found that I needed to modify all
> my dictionary files by hand to put the Alias and field name into lower
> case. I also removed the double ups that were being generated and
> touched up our custom Agencyvalidator.cfc code to use all lower
> case.This was a long and painful process but it seemed to resolve the
> issue.
>
> However it was not long until we started banging our heads against a
> new problem... the
>
/reactor/project/projectName/validator/AgencyValidator.cfc
is still
> generating mixed case error message which also results in dictionary
> misses (and therefore objectTranslator.cfc errors).
>
> These are being generated by
>
http://trac.reactorframework.org/reactor/browser/trunk/reactor/xsl/validator.project.xsl
> (lines 57, 76, etc..), where the object names are NOT being lower
> cased. This is also not detailed in the comments of
> http://trac.reactorframework.org/reactor/ticket/56.
>
> So what do we do?
>
> I can think of 3 options:
>
> a) Make all our tables and fields lower case.
> b) Change validator.project.xsl to lower case the generated error codes.
> c) Roll back 331
>
> I think a) is a definite mistake - what if we are working on a legacy
> DB that we don't own?
>
> b) could be an option, but I don't actually see what 331 achieves so I
> would not rule out option c) either.
>
> What is really perplexing me is my has no one else encoutered this
> problem? Is everyone running something pre 331? Is everyone using
> lower case alias and field names? Is no one using the validation? Am I
> losing the plot and missing something completely?
>
> Interested in your thoughts.
>
>
> Mark
>
>
>
> --
> Mark Stanton
> Gruden Pty Ltd
> http://www.gruden.com
>
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
> Reactor for ColdFusion Mailing List
> [email protected]
> Archives at:
http://www.mail-archive.com/reactor%40doughughes.net/
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
>
>
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at:
http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- --
--
Mark Stanton
Gruden Pty Ltd
http://www.gruden.com
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
