accessing type.properties

[Joshua Paine]

You can get all your object's type's properties like this:

function getTypeProperties(){
   var hash = {}, name, names, props;
   props = app.getPrototype(this._prototype.toString())
     .getTypeProperties();
   names = props.propertyNames();
   while(names.hasNext() && (name = names.next()))
     hash[name] = props.getProperty(name);
   return hash;
}

Unfortunately the original getTypeProperties returns a hash-like
structure, so as far as I can tell there's no way to get them in order.
Does anyone know if there is a way to get the types properties in their
original order without reading the file?


_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user

[Breton Slivka]

Out of curiosity, why do you need them in the original order?

On Thu, Jul 3, 2008 at 3:17 AM, Joshua Paine <joshua@...> wrote:

> You can get all your object's type's properties like this:
>
> function getTypeProperties(){
>   var hash = {}, name, names, props;
>   props = app.getPrototype(this._prototype.toString())
>     .getTypeProperties();
>   names = props.propertyNames();
>   while(names.hasNext() && (name = names.next()))
>     hash[name] = props.getProperty(name);
>   return hash;
> }
>
> Unfortunately the original getTypeProperties returns a hash-like
> structure, so as far as I can tell there's no way to get them in order.
> Does anyone know if there is a way to get the types properties in their
> original order without reading the file?
>
>
> _______________________________________________
> Helma-user mailing list
> Helma-user@...
> http://helma.org/mailman/listinfo/helma-user
>

_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user

[Joshua Paine]

Breton Slivka wrote:
> Out of curiosity, why do you need them in the original order?

I'm trying to cut down my boilerplate code and make basic CRUD as quick
to do as reasonably possible. I dislike code generation--boilerplate is
not less boilerplate because a script wrote it for me. Instead I want
generic routines that just work for the basic case and have enough hooks
in them that they can be customized for most other cases. So I've got
code that handles automatically and cleanly one of the vexed issues of
Helma app organization: how do I let MyType be responsible for its own
creation view and controller code and not ParentOfMyType? (Contrast with
the addressbook tutorial, where create.hac is part of Root, not Person,
and though it shares the skin duplicates almost all the logic code of
Person/edit.) And I've got code that automatically handles
updating/creating an object from POST data--works for a very large
subset of cases and easy to override where it wouldn't. And I've got
code that makes building adequately pretty, smart forms that are aware
of the object they belong to very quick. The goal in all these is to
reduce code size *and* occasion for error. (Contrast a form validation
lib I once wrote that used a very compact DSL--so compact I was always
having to look up what I meant.)

Anyway, to go all the way to automated CRUD, I need some way of saying
what order the fields go in. And I'd like to say it without any
duplication of information--i.e., I don't even want to say the names of
all the properties over again. They're all in type.properties already,
so ideally I could just put them there in the order I want them
presented in. And since I want this automation to happen in real time,
not generated, it seems like reading the file and parsing it over again
would be a bit wasteful. I suppose I could cache the result of the
reading/parsing, but that's still more pain than I'd like for this purpose.
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user

[Breton Slivka-2]

In the spirit of idea generation, here's a very silly solution:

Sort all the property names alphabetically (or some known other known
sort ordering function),
And then specify the order of the fields as a permutation of that
original order using a factoradic.

http://en.wikipedia.org/wiki/Factoradic

Once you convert a factoradic into a machine integer, it's *the* most
compact way of specifying the order of anything you'll find.


-----Original Message-----
From: helma-user-bounces@... [mailto:helma-user-bounces@...]
On Behalf Of Joshua Paine
Sent: Thursday, 3 July 2008 12:20 PM
To: Helma User Mailing List
Subject: Re: [Helma-user] accessing type.properties

Breton Slivka wrote:
> Out of curiosity, why do you need them in the original order?

I'm trying to cut down my boilerplate code and make basic CRUD as quick
to do as reasonably possible. I dislike code generation--boilerplate is
not less boilerplate because a script wrote it for me. Instead I want
generic routines that just work for the basic case and have enough hooks
in them that they can be customized for most other cases. So I've got
code that handles automatically and cleanly one of the vexed issues of
Helma app organization: how do I let MyType be responsible for its own
creation view and controller code and not ParentOfMyType? (Contrast with
the addressbook tutorial, where create.hac is part of Root, not Person,
and though it shares the skin duplicates almost all the logic code of
Person/edit.) And I've got code that automatically handles
updating/creating an object from POST data--works for a very large
subset of cases and easy to override where it wouldn't. And I've got
code that makes building adequately pretty, smart forms that are aware
of the object they belong to very quick. The goal in all these is to
reduce code size *and* occasion for error. (Contrast a form validation
lib I once wrote that used a very compact DSL--so compact I was always
having to look up what I meant.)

Anyway, to go all the way to automated CRUD, I need some way of saying
what order the fields go in. And I'd like to say it without any
duplication of information--i.e., I don't even want to say the names of
all the properties over again. They're all in type.properties already,
so ideally I could just put them there in the order I want them
presented in. And since I want this automation to happen in real time,
not generated, it seems like reading the file and parsing it over again
would be a bit wasteful. I suppose I could cache the result of the
reading/parsing, but that's still more pain than I'd like for this
purpose.
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user


Breton Slivka
Assistant Multimedia Systems Developer

National Gallery of Victoria
180 St Kilda Road Melbourne Vic 3004 Australia
Telephone: [phone]
Fax: [phone]
ngv.vic.gov.au

Keep informed of the latest NGV exhibitions, special events and programs at The Ian Potter Centre: NGV Australia and NGV International by subscribing to NGV@RT, the NGV's free e-newsletter.

DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for helma-user@.... If you are not the named addressee you should not disseminate, copy or alter this email. WARNING: Although National Gallery of Victoria has taken reasonable precautions to ensure no viruses are present in this email, the organisation cannot accept responsibility for any loss or damage arising from the use of this email or attachment.
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user

[Joshua Paine]

Breton Slivka wrote:
> In the spirit of idea generation, here's a very silly solution:

Maybe I should make it an explicit design goal that someone reading the
code should not have to consult wikipedia. :-)

> Once you convert a factoradic into a machine integer, it's *the* most
> compact way of specifying the order of anything you'll find.

Except not having to specify it seperately at all, which is what being
able to read the type properties in order would get me.
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user

[Breton Slivka-2]

Okay, to be more serious. I was actually quite stoked by your initial
email. Why? Because I didn't know you could programatically read
type.properties at all! You know what else you can do? You can set it
programatically. I immediately set out to write an example of replacing
type.properties with an Object Literal in javascript. That's as follows:


ArtworkType.js:

jsonType(
"Artwork",
{
        "_id" : "ARTWORK_ID",
        "_db" : GlobalDatabase,              // a global variable set
earlier.
        "artist": "ARTIST_ID",              
        "year": "YEAR",
        "title": "TITLE
});



Global.js:

function jsonType(prototypename, json) {
       
        var typeproperties =
app.getPrototype(prototypename).getTypeProperties();
        var i;
        for(i in json) {
                typeproperties.setProperty(i, json[i]);
        }

        return jsonType;  //This enables some nice chaining.
}


 
>From here it's not that much of a leap to make the original "json"
object an array like so:

ArtworkType = [
        {"_id" : "ARTWORK_ID"},
        {"_db" : GlobalDatabase},              // a global variable set
earlier.
        {"artist": "ARTIST_ID"},              
        {"year": "YEAR"},
        {"title": "TITLE}
]

Then modify the jsonType function accordingly:

jsonType("Artwork", ArtworkType)

And bam, you've got type.properties as a literal, throw away the
type.properties file.
And not only that, but you can then go on to query the ArtworkType
object to generate forms, in the order that you want, and everything is
specified in only one place.


-----Original Message-----
From: helma-user-bounces@... [mailto:helma-user-bounces@...]
On Behalf Of Joshua Paine
Sent: Thursday, 3 July 2008 12:56 PM
To: Helma User Mailing List
Subject: Re: [Helma-user] accessing type.properties

Breton Slivka wrote:
> In the spirit of idea generation, here's a very silly solution:

Maybe I should make it an explicit design goal that someone reading the
code should not have to consult wikipedia. :-)

> Once you convert a factoradic into a machine integer, it's *the* most
> compact way of specifying the order of anything you'll find.

Except not having to specify it seperately at all, which is what being
able to read the type properties in order would get me.
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user


Breton Slivka
Assistant Multimedia Systems Developer

National Gallery of Victoria
180 St Kilda Road Melbourne Vic 3004 Australia
Telephone: [phone]
Fax: [phone]
ngv.vic.gov.au

Keep informed of the latest NGV exhibitions, special events and programs at The Ian Potter Centre: NGV Australia and NGV International by subscribing to NGV@RT, the NGV's free e-newsletter.

DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for helma-user@.... If you are not the named addressee you should not disseminate, copy or alter this email. WARNING: Although National Gallery of Victoria has taken reasonable precautions to ensure no viruses are present in this email, the organisation cannot accept responsibility for any loss or damage arising from the use of this email or attachment.
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user

[Joshua Paine]

Breton Slivka wrote:
> You know what else you can do? You can set it programatically.

I saw those methods when I was investigating this, but didn't think to
try anything with them. (Maybe 'cause type.properties never really
bothered me?)

> I immediately set out to write an example of replacing
> type.properties with an Object Literal in javascript.

Is this tested and working? Does it work for all properties, even
_extends? Since helma will see and use changes to types while running
already, I guess this should work. Would love to hear from Hannes that
this won't cause lots of expensive cache invalidations that wouldn't
happen otherwise.

Really cool, though. And now that the possibility of controlling
type.properties from script appears, I begin to think of some things I'd
do with it.


I was going to reply with my discovery that you can put arbitrary named
values in type.properties, and if you start with _ and they're not magic
helma ones, they won't affect anything. So it'd be easy to specify the
order there--still a bit of repeating oneself, but all in one place at
least. This is a lot more interesting, though, and suggests ways to
optionally put more metadata into the [script version of] type
properties to get better forms for minimal effort.
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user

[Breton Slivka-2]

It's a brand spanking new idea, so nothing is tested yet. Not by me at
least. But it certainly is worth looking more into this. I'll do what I
can. My associate Maks has also taken interest in my invention, so I
imagine he'll be looking into it as well.


 

-----Original Message-----
From: helma-user-bounces@... [mailto:helma-user-bounces@...]
On Behalf Of Joshua Paine
Sent: Thursday, 3 July 2008 1:32 PM
To: Helma User Mailing List
Subject: Re: [Helma-user] accessing type.properties

Breton Slivka wrote:
> You know what else you can do? You can set it programatically.

I saw those methods when I was investigating this, but didn't think to
try anything with them. (Maybe 'cause type.properties never really
bothered me?)

> I immediately set out to write an example of replacing type.properties

> with an Object Literal in javascript.

Is this tested and working? Does it work for all properties, even
_extends? Since helma will see and use changes to types while running
already, I guess this should work. Would love to hear from Hannes that
this won't cause lots of expensive cache invalidations that wouldn't
happen otherwise.

Really cool, though. And now that the possibility of controlling
type.properties from script appears, I begin to think of some things I'd
do with it.


I was going to reply with my discovery that you can put arbitrary named
values in type.properties, and if you start with _ and they're not magic
helma ones, they won't affect anything. So it'd be easy to specify the
order there--still a bit of repeating oneself, but all in one place at
least. This is a lot more interesting, though, and suggests ways to
optionally put more metadata into the [script version of] type
properties to get better forms for minimal effort.
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user


Breton Slivka
Assistant Multimedia Systems Developer

National Gallery of Victoria
180 St Kilda Road Melbourne Vic 3004 Australia
Telephone: [phone]
Fax: [phone]
ngv.vic.gov.au

Keep informed of the latest NGV exhibitions, special events and programs at The Ian Potter Centre: NGV Australia and NGV International by subscribing to NGV@RT, the NGV's free e-newsletter.

DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for helma-user@.... If you are not the named addressee you should not disseminate, copy or alter this email. WARNING: Although National Gallery of Victoria has taken reasonable precautions to ensure no viruses are present in this email, the organisation cannot accept responsibility for any loss or damage arising from the use of this email or attachment.
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user

[Breton Slivka-2]

FYI, I played with it for a little while, and it just needs one magic
little "bump"

Once you've written a new type.properties (via the setProperty
function), you need to call the update() function to make helma read it
in.  Example:

 app.getPrototype("Artwork").getDbMapping().update();

And then your dynamica changes will be seen by helma.


-----Original Message-----
From: helma-user-bounces@... [mailto:helma-user-bounces@...]
On Behalf Of Breton Slivka
Sent: Thursday, 3 July 2008 1:39 PM
To: Helma User Mailing List
Subject: Re: [Helma-user] accessing type.properties

It's a brand spanking new idea, so nothing is tested yet. Not by me at
least. But it certainly is worth looking more into this. I'll do what I
can. My associate Maks has also taken interest in my invention, so I
imagine he'll be looking into it as well.


 

-----Original Message-----
From: helma-user-bounces@... [mailto:helma-user-bounces@...]
On Behalf Of Joshua Paine
Sent: Thursday, 3 July 2008 1:32 PM
To: Helma User Mailing List
Subject: Re: [Helma-user] accessing type.properties

Breton Slivka wrote:
> You know what else you can do? You can set it programatically.

I saw those methods when I was investigating this, but didn't think to
try anything with them. (Maybe 'cause type.properties never really
bothered me?)

> I immediately set out to write an example of replacing type.properties

> with an Object Literal in javascript.

Is this tested and working? Does it work for all properties, even
_extends? Since helma will see and use changes to types while running
already, I guess this should work. Would love to hear from Hannes that
this won't cause lots of expensive cache invalidations that wouldn't
happen otherwise.

Really cool, though. And now that the possibility of controlling
type.properties from script appears, I begin to think of some things I'd
do with it.


I was going to reply with my discovery that you can put arbitrary named
values in type.properties, and if you start with _ and they're not magic
helma ones, they won't affect anything. So it'd be easy to specify the
order there--still a bit of repeating oneself, but all in one place at
least. This is a lot more interesting, though, and suggests ways to
optionally put more metadata into the [script version of] type
properties to get better forms for minimal effort.
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user


Breton Slivka
Assistant Multimedia Systems Developer

National Gallery of Victoria
180 St Kilda Road Melbourne Vic 3004 Australia
Telephone: [phone]
Fax: [phone]
ngv.vic.gov.au

Keep informed of the latest NGV exhibitions, special events and programs
at The Ian Potter Centre: NGV Australia and NGV International by
subscribing to NGV@RT, the NGV's free e-newsletter.

DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for helma-user@.... If you are
not the named addressee you should not disseminate, copy or alter this
email. WARNING: Although National Gallery of Victoria has taken
reasonable precautions to ensure no viruses are present in this email,
the organisation cannot accept responsibility for any loss or damage
arising from the use of this email or attachment.
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user

[Joshua Paine]

*sigh* you're a step ahead again. I just found that, too.

I can add that prototypes that _extend the one you're updating get
updated, too. And it works (as we would want) even if there's no
type.properties file at all.

So, wow. Cool evening's worth of playing around. I think we jusr got rid
of type.properties.
_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user