headers
Joshua Paine | 2 Jul 19:17

accessing type.properties

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?
Permalink | Reply | 2 comments |
headers
Breton Slivka | 3 Jul 03:49
Favicon

Re: accessing type.properties

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

On Thu, Jul 3, 2008 at 3:17 AM, Joshua Paine <joshua <at> papercrown.org> 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 <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
>
Permalink | Reply | 1 comment |
headers
Joshua Paine | 3 Jul 04:19

Re: 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Breton Slivka | 3 Jul 04:45
Picon

Re: accessing type.properties

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 <at> helma.org [mailto:helma-user-bounces <at> helma.org]
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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joshua Paine | 3 Jul 04:55

Re: 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.
Permalink | Reply | 0 comments |
headers
Breton Slivka | 3 Jul 05:04
Picon

Re: accessing type.properties

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]);
	}
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joshua Paine | 3 Jul 05:32

Re: 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.
Permalink | Reply | 0 comments |
headers
Breton Slivka | 3 Jul 05:39
Picon

Re: 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 <at> helma.org [mailto:helma-user-bounces <at> helma.org]
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Breton Slivka | 3 Jul 06:31
Picon

Re: accessing type.properties

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 <at> helma.org [mailto:helma-user-bounces <at> helma.org]
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 <at> helma.org [mailto:helma-user-bounces <at> helma.org]
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
(Continue reading)

Permalink | Reply | 501 comments |
headers
Joshua Paine | 3 Jul 06:45

Re: accessing type.properties

*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.
Permalink | Reply | 501 comments |

Gmane