[Helma-user] accessing type.properties

[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.