Hidden Fields

[ConvertFromOldNGs]

by Brian Mills >> Sun, 7 Nov 2004 22:28:37 GMT

I have just upgraded one of our systems to Jade 6 for a trial and found a few properties that were in use are no longer available under their current names. Does anyone know how to get the two fields below?


Iterator :: __relativeIndex
Property :: __subschemaHidden

Any help would be apreciated.

Brian.

[ConvertFromOldNGs]

by Patwos >> Mon, 8 Nov 2004 20:02:16 GMT

In Jade 6 you can now mark your own schema entities as "subschema hidden". For example, you can define methods as subschema hidden when adding a new method.

I suspect you'll find that the internal implementations in RootSchema, particularly those properties/methods that begin with an underscore character, are now being made inaccessible to user schemas.

I'd recommend removing your use of undocumented/hidden properties and methods from your system as these can be changed/removed without notice causing your application to "break" when you upgrade to a release where this happens.

Hope that helps,
Pat.

[ConvertFromOldNGs]

by Brian Mills >> Mon, 8 Nov 2004 23:43:06 GMT

I understand your point. Unfortuntaley these undocumented features were required to get the job done as I understand it. The worst bit is that I didnt actually write the code, so I'm going to have to spend some time working out why and what these undocumented features did.

I dont actually see reason to have undocumented features. If they were usefull at the Jade level to get the job done efficiently, with all likeleyhood they would be usefull for people inheriting from RootSchema/JadeSchema.

What do other people think?

Brian.

[ConvertFromOldNGs]

by allistar >> Tue, 9 Nov 2004 4:39:30 GMT

I think any methods or properties that us developers can "discover" should be avaiable to use. If they were not intended for use then in my mind they should not be able to be discovered. Having said that if methods that were obviously not intended for use are used, then it is fair to anticipate them disappearing.

JADE provides just enough access to the meta-data to allow discovery of all the other metadata (like hidden properties and methods). I know that I use this metadata quite often, but only in scripts and methods to aid development - not in user aplications.

Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

[ConvertFromOldNGs]

by Patwos >> Tue, 9 Nov 2004 6:00:03 GMT

I'm sure you'll agree that there are times where you do not want to expose the internal workings of your own application schema classes and therefore have both public and private interfaces within those classes for performing the desired work. In this way, you can easily change the internal workings of your class without any negative impact on users of your class if these changes do not impact on the public interface for that class. This is particular the case if you're developing a package schema for other users to import. Obviously it is far easier to change the internal workings when you do not need to concern yourself with the impact of any changes to these "hidden/undocumented" methods. It's also nice not to have to document all of them as well and I'm sure the same applies to the Jade developers responsible for RootSchema properties/methods.

As Allistar has said, these internal meta-data classes/methods can be useful in scripts, but I also avoid using them in production application code. One would hope you're not attempting to utilise properties/classes/methods from JadeSchema given that this would prevent your application from running in a deployed environment where JadeSchema does not exist.

Lastly, I'm also a fan of the KISS principle. In a number of cases where I've seen people utilising some undocumented methods, they could easily have achieved their desired result in an alternate, and often more obvious manner. Over a few drinks, the developers of such methods will often admit they did it that way "because they could" and because sometimes it's nice to be able to "show off" with some smart/generic code. Particularly given that it takes a little more exercise of the grey cells to write this style of code, and is therefore more interesting than just writing some "grunt code" that would have still achieved the desired result albeit with a little less "feel good satisfaction" factor....

Pat.

PS: Soap box available for rent.... just $0.02.