Re: accessing type.properties
"Breton Slivka" <[email protected]> Thu, 3 Jul 2008 12:45:56 +1000
| Newsgroups | gmane.comp.java.helma.general |
|---|---|
| Message-ID | <[email protected]> |
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: [email protected] [mailto:[email protected]] 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 [email protected] 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@RT, the NGV's free e-newsletter. DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for [email protected]. 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.