[Helma-user] accessing type.properties

[Breton Slivka]

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
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 at helma.org
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: +61 3 8620 2348 
Fax: +61 3 8620 2555
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 at RT, the NGV's free e-newsletter.

DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for helma-user at helma.org. 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.