Rails - Sep 2005 - Incoherent babbling about special cases and reuse

Luckily for me, I don''t actually have this project yet, but
I''ve been
thinking about it in my spare time, in case it ends up in my lap.
Imagine a system that accepts "applications" for some nebulous
collection of resources, assets, etc.  I''m not in the banking
industry, but presumably there are 100 different kinds of loans, lines
of credit, etc that customers can apply for.
Despite this, the customer is going to want a unified front-end for
these things, and adding/removing them later should be as easy as
possible.

Many of the fields will be common between every type; for example, any
application for anything is going to ask for the name of the
applicant.  Others may not be identical; one application might require
a social security number or driver''s license number, another may not
ask for it at all, and yet another may have a field for it, but make
it optional.

Because of these similarities, I think it makes sense to keep the
number of tables/models as small as possible.  One table per
application type works fine if you have three types; not well at all
if you have ninety.

How have other people conquered the round-trip issue from the data,
through the validation in the model, out to the page template?
Having fifty views for fifty types of app would be a nightmare, but
similarly you don''t want your views filled with acres of conditional
code.

Is there a design pattern I''m forgetting about?  This reminds me
vaguely of the "Special Case" pattern in Fowler''s book, but
that
really only deals with a single parent class, not with the end-to-end
behavior of the system as a whole.

Another thing that comes to mind is the conditional behavior you tend
to see in authentication systems.. e.g. link_to(something) if
user.is_an_admin?.  What if you had 100 roles in your security model?

I''m pulling stuff out of the air here, but what about a HABTM
relationship between application types and their characteristics?
some_app.type = 10 # Application for free widgets, only walruses are eligible.
some_app.fields_for_this_type.each do |field|
  ...<code that dynamically sets model properties for this instance>..
end
etc.

Am I planning to reinvent the wheel here? Anyone want to show off some
battle-scars from tackling this kind of madness?

Regards,
--Wilson.

Interesting ideas... only have time to reply to one thing
>
> Another thing that comes to mind is the conditional behavior you tend
> to see in authentication systems.. e.g. link_to(something) if
> user.is_an_admin?.  What if you had 100 roles in your security model?
>
Anything more complicated than user.is_an_admin? usually gets  
refactored into a full RBACL system with hierarchical roles. The  
Metadot CMS (www.metadot.com)--though Perl--has a fairly well- 
developed access control system. The view code can be pretty clean:

link_to(manage_something) if user.can(:manage_something)

In general, I like this kind of thinking. It''s nice to be able to  
abstract an aspect almost completely away. I''d be interested.

be

That makes sense. In an access control system, you''re worried about
the capabilities of the user, not the name of the group they are part
of.  Similarly, in this example we only care about the properties of
the instance object.. we desperately don''t want to care/know what kind
it is, when it comes to deciding what to validate and what to show in
the view.
Oh, and I definitely meant this, instead of what I wrote..
some_app.type.each_field do |field|
  <metaprogramming voodoo goes here>
end

I think I need to get over my hangups about depending too much on the
database.  The data IS the app; the data is integral the behavior.

The existing system I''m thinking of replacing has something like 10
million lines of code, and I''m fairly confident that most of them were
written because the original developers couldn''t come up with a way to
abstract away all these special cases.

Thanks for the reply, by the way.  I''m glad to know I''m not
entirely
insane.  Possibly just mostly.

--Wilson.

On 9/27/05, Brad Ediger <brad-sod+mMc99o6+XT7JhA+gdA@public.gmane.org>
wrote:
> Interesting ideas... only have time to reply to one thing
>
> >
> > Another thing that comes to mind is the conditional behavior you tend
> > to see in authentication systems.. e.g. link_to(something) if
> > user.is_an_admin?.  What if you had 100 roles in your security model?
> >
>
> Anything more complicated than user.is_an_admin? usually gets
> refactored into a full RBACL system with hierarchical roles. The
> Metadot CMS (www.metadot.com)--though Perl--has a fairly well-
> developed access control system. The view code can be pretty clean:
>
> link_to(manage_something) if user.can(:manage_something)
>
> In general, I like this kind of thinking. It''s nice to be able to
> abstract an aspect almost completely away. I''d be interested.
>
> be
>
>
>

On 9/27/05, Steven <critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org>
wrote:
> On Tue, 2005-09-27 at 19:10 -0400, Wilson Bilkovich wrote:
> >
> > Another thing that comes to mind is the conditional behavior you tend
> > to see in authentication systems.. e.g. link_to(something) if
> > user.is_an_admin?.  What if you had 100 roles in your security model?
>
<snip>
> As for your own problem. I have a couple of questions that you may want
> to ask about your data. Do you need to search based on the non shared
> criteria? If not, then you very well may want to think about serializing
> that data into one extended properties column.
Haha. I had just started to think about this when your e-mail came in.
I think in this scenario I could potentially get away with not being
able to search on arbitrary fields, and restricting queries to shared
properties only.  On the other hand, finding out that this wasn''t true
after you had built the thing would be unpleasant in the extreme.

Edit:
I had a big paragraph written here, with some fun ASCII art, but when
I got to the end I realized that there was still no way to store "app
instances" without a table with every possible column in it. Once
you''ve got that, you might as well just have single-table inheritance
and a ''properties_types'' join table for runtime properties.
Hrm. More thought is clearly necessary.

On Tue, 2005-09-27 at 19:10 -0400, Wilson Bilkovich
wrote:
> Many of the fields will be common between every type; for example, any
> application for anything is going to ask for the name of the
> applicant.  Others may not be identical; one application might require
> a social security number or driver''s license number, another may
not
> ask for it at all, and yet another may have a field for it, but make
> it optional.
> 
> Because of these similarities, I think it makes sense to keep the
> number of tables/models as small as possible.  One table per
> application type works fine if you have three types; not well at all
> if you have ninety.
> 
> How have other people conquered the round-trip issue from the data,
> through the validation in the model, out to the page template?
> Having fifty views for fifty types of app would be a nightmare, but
> similarly you don''t want your views filled with acres of
conditional
> code.
> 
> Is there a design pattern I''m forgetting about?  This reminds me
> vaguely of the "Special Case" pattern in Fowler''s book,
but that
> really only deals with a single parent class, not with the end-to-end
> behavior of the system as a whole.
> 
> Another thing that comes to mind is the conditional behavior you tend
> to see in authentication systems.. e.g. link_to(something) if
> user.is_an_admin?.  What if you had 100 roles in your security model?
Security is a fun beast of it''s own. We are conquering it with a
SELinux
policy style solution. Can''t wait to get it a bit further along to be
able to share it with the rest of you.

As for your own problem. I have a couple of questions that you may want
to ask about your data. Do you need to search based on the non shared
criteria? If not, then you very well may want to think about serializing
that data into one extended properties column. 

I would then suggest building a configuration type of object that can be
reference when you need to figure out what extra data you will need to
complete that application type. You can then create those attributes on
your object to be displayed via something like scaffolding. 

You can also consult the same configuration information to pluck params
out of a form to populate your object before saving it away. You may
even consult the configuration object for a list of validates rules that
should be called on your extended attributes before saving. 

Those are ideas that came up before we realized we had to be able to
search by the data that might have been serialized. We then chose to
bite the bullet and split our application differently. Our other
solution doesn''t seem to match with your problem.
-- 
Steven Critchfield
critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org
KI4KTY

On 27-Sep-05, at 4:37 PM, Brad Ediger wrote:
> Anything more complicated than user.is_an_admin? usually gets 
> refactored into a full RBACL system with hierarchical roles. The 
> Metadot CMS (www.metadot.com)--though Perl--has a fairly 
> well-developed access control system. The view code can be pretty 
> clean:
>
> link_to(manage_something) if user.can(:manage_something)
>
Also, if you''re wanting the link text to appear sans-link if the 
condition is false rails lets you:

link_to_if user.can(:manage_something), ''Manage'', yadda,
yadda, yadda

Trevor

Hi Wilson,

I had a *slightly* similar situation, though on a much smaller scale,
which *might* provide *some* insight.

The similarity between your forms is mostly what made me think of my
experience. In that situation, I was only looking at 20 forms, and
their derivation was minimal. Nonetheless, I found it to be useful to
use an XML file to describe all the possible fields for any given
form, and then use a group of custom tags to generate them. Something
like...

<form:field id="foo">

... might generate ...

<label for="foo">foo</label>
<input type="text" id="foo" name="foo" />

In my case, I believe I used seperate helpers for different types of
input, e.g. <select /> or <textarea />. However, it might be smarter
to describe all that in the XML. * shrug *

I didn''t have to deal with storing the filled out applications in a
database, though. I simply sent off an email. But perhaps you could
get away with something like a single applications table that could
somehow describe which fields were used in an application, and the
values the user supplied for said fields, without requiring columns
for every field, of course.

* again, shrug *

I dunno how relevant or useful any of that is, but as I said, my
approach to the views seemed very good at the time, and though I''d
change some details if I had to tackle a similar problem again, it
still seems like a sound enough general approach. Since you will be
using a database for the whole thing, you''d probably wanna forego the
XML file and just have a couple tables: fields and fields_types or
something.

On Tue, 2005-09-27 at 20:13 -0400, Wilson Bilkovich
wrote:
> On 9/27/05, Steven <critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org>
wrote:
> > On Tue, 2005-09-27 at 19:10 -0400, Wilson Bilkovich wrote:
> > >
> > > Another thing that comes to mind is the conditional behavior you
tend
> > > to see in authentication systems.. e.g. link_to(something) if
> > > user.is_an_admin?.  What if you had 100 roles in your security
model?
> >
> <snip>
> > As for your own problem. I have a couple of questions that you may
want
> > to ask about your data. Do you need to search based on the non shared
> > criteria? If not, then you very well may want to think about
serializing
> > that data into one extended properties column.
> 
> Haha. I had just started to think about this when your e-mail came in.
> I think in this scenario I could potentially get away with not being
> able to search on arbitrary fields, and restricting queries to shared
> properties only.  On the other hand, finding out that this wasn''t
true
> after you had built the thing would be unpleasant in the extreme.
It just occurred to me that you might be able to store these extra
properties as a YAML document in a db column. The predictable format
would allow you to do searches via text searching. 

Or going really odd and out there, just tossing out as an idea to solve
the problem..... Use postgres and plruby and make a read view that lets
you view the serialized data as parts of your record when reading and
maybe does the serializing for you when storing.

Down side to that is it puts a lot of intelligence out in your data
storage, and it very well might not work. It will give me something kind
of interesting to try playing with later when I want a brain teaser.

-- 
Steven Critchfield
critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org
KI4KTY

>
> Also, if you''re wanting the link text to appear sans-link if the  
> condition is false rails lets you:
>
> link_to_if user.can(:manage_something), ''Manage'', yadda,
yadda, yadda
>
> Trevor
>
Cool -- I didn''t know that. That would have helped me out about 2  
hours ago when I was doing a bunch of if... link_to ... else ... end  
statements :-)

Thanks,
be

On Sep 27, 2005, at 8:31 PM, Steven wrote:
> On Tue, 2005-09-27 at 20:13 -0400, Wilson Bilkovich wrote:
>
>> On 9/27/05, Steven
<critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org> wrote:
>>
>>> On Tue, 2005-09-27 at 19:10 -0400, Wilson Bilkovich wrote:
>>>
>>>>
>>>> Another thing that comes to mind is the conditional behavior
you
>>>> tend
>>>> to see in authentication systems.. e.g. link_to(something) if
>>>> user.is_an_admin?.  What if you had 100 roles in your security
>>>> model?
>>>>
>>>
>>>
>> <snip>
>>
>>> As for your own problem. I have a couple of questions that you  
>>> may want
>>> to ask about your data. Do you need to search based on the non  
>>> shared
>>> criteria? If not, then you very well may want to think about  
>>> serializing
>>> that data into one extended properties column.
>>>
>>
>> Haha. I had just started to think about this when your e-mail came  
>> in.
>> I think in this scenario I could potentially get away with not being
>> able to search on arbitrary fields, and restricting queries to shared
>> properties only.  On the other hand, finding out that this
wasn''t
>> true
>> after you had built the thing would be unpleasant in the extreme.
>>
>
> It just occurred to me that you might be able to store these extra
> properties as a YAML document in a db column. The predictable format
> would allow you to do searches via text searching.
>
> Or going really odd and out there, just tossing out as an idea to  
> solve
> the problem..... Use postgres and plruby and make a read view that  
> lets
> you view the serialized data as parts of your record when reading and
> maybe does the serializing for you when storing.
>
> Down side to that is it puts a lot of intelligence out in your data
> storage, and it very well might not work. It will give me something  
> kind
> of interesting to try playing with later when I want a brain teaser.
I tend to be more of the "let the database do the database work"  
school of thought. I''ve had bad experiences (also with the Metadot  
CMS) because access control was a serialized data structure -- in  
BINARY!! </rant> Anyway, YAML would probably be more workable but it  
seems Active Record provides most of the data structures (I''m  
thinking STI, aggregations, and relations) needed to implement these  
properties. I would tend to normalize and link to another table:  
(i.e. record has_many :ExtendedProperties)

(pseudo-SQL)
CREATE TABLE ExtendedProperties (
   id int not null,
   property_name varchar(255),
   property_value whatever,
   primary key (id)
);



_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On 9/27/05, Seth Rasmussen
<seths.mailing.lists-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I didn''t have to deal with storing the filled out applications in
a
> database, though. I simply sent off an email. But perhaps you could
> get away with something like a single applications table that could
> somehow describe which fields were used in an application, and the
> values the user supplied for said fields, without requiring columns
> for every field, of course.
Okay, so here''s my stab at it:

The structure of the database could be such that each *type* of field
(type of question, really, with an associated input element that suits
it) that could occur anywhere, in any form is described in a lookup
table (perhaps application_line_item_type).  An application_line_items
table describes each field in a given form by giving a foreign key to
the application_line_item_type table and the basic information that is
required to customize this field, for instance: (text_field, label,
default_value, class, styleid, name)

Which supplies enough data to construct a single question on the form.
 Building an entire application would be consisted of a series of line
items all linked by a common FK to the applications table (which
consists of id, name and description).  To render a form you would
join these tables and output the HTML specified by the returned
values.

Saving the form would another table, answer_line_items which stores
user_id, application_line_item_id, application_id and answer.

Sound plausible?

- Stephen

On 9/27/05, Brad Ediger <brad-sod+mMc99o6+XT7JhA+gdA@public.gmane.org>
wrote:
>
> Cool -- I didn''t know that. That would have helped me out about 2
> hours ago when I was doing a bunch of if... link_to ... else ... end
> statements :-)
On that note, I''ve found it useful to modify link_to_if so that it
wraps the text in a span, if the condition is not satisfied... makes
styling it much easier.

in application_helper.rb:

	def link_to_else_span(condition,*args)
		link_to_unless(!condition, *args) {|name|
"<span>#{name}</span>"}
	end

in your view:

<%= link_to_else_span  user.can(:manage_something),''Manage This
thing'',{:controller => ''manage'', :action =>
''thing''} %>

- Stephen

Interesting idea. I like it.
Does anyone have any experience with these so-called XML databases?  I
know that there are Oracle features to support this now, but I haven''t
tried them yet.
It seems to me that their intent is to let you jam XML into a field,
yet select it, search it, etc, as if the XML elements were themselves
properties of the database table.
You could then just have an "application types" table that held the
XML descriptions of your different categories of
''application'', and an
''applications'' table holding the actual instances.

--Wilson.

On 9/27/05, Stephen Caudill
<scaudill-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 9/27/05, Seth Rasmussen
<seths.mailing.lists-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > I didn''t have to deal with storing the filled out
applications in a
> > database, though. I simply sent off an email. But perhaps you could
> > get away with something like a single applications table that could
> > somehow describe which fields were used in an application, and the
> > values the user supplied for said fields, without requiring columns
> > for every field, of course.
>
> Okay, so here''s my stab at it:
>
> The structure of the database could be such that each *type* of field
> (type of question, really, with an associated input element that suits
> it) that could occur anywhere, in any form is described in a lookup
> table (perhaps application_line_item_type).  An application_line_items
> table describes each field in a given form by giving a foreign key to
> the application_line_item_type table and the basic information that is
> required to customize this field, for instance: (text_field, label,
> default_value, class, styleid, name)
>
> Which supplies enough data to construct a single question on the form.
>  Building an entire application would be consisted of a series of line
> items all linked by a common FK to the applications table (which
> consists of id, name and description).  To render a form you would
> join these tables and output the HTML specified by the returned
> values.
>
> Saving the form would another table, answer_line_items which stores
> user_id, application_line_item_id, application_id and answer.
>
> Sound plausible?
>
> - Stephen
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

I have a similar problem with the design of a legal application. There are
over 60 prescribed forms that the public fill out pertaining to events that
occur in the life of a company. Example: Register, Notify of a change of
Secretary, Notify of a Change of Directors, File Mortgages etc...
 Filling a particular form will trigger a change in the companies records
once the information checked and verified.
 The application must be able to work against multiple Jurisdictions, which
have almost the same requirements with small changes in the forms.
 It would have been lovely to have some kind of a form builder to create
custom fields and control meta data in a software application.
 Some Desirable features
--Create Libraries of Questions
--Conditional branching- Set questions depending on earlier answers
--Some method of binding actions to model methods
 I am interesting in how the community members would have dealt with such a
problem.
 Regards,
Leon Leslie

 On 9/28/05, Wilson Bilkovich
<wilsonb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Interesting idea. I like it.
> Does anyone have any experience with these so-called XML databases? I
> know that there are Oracle features to support this now, but I
haven''t
> tried them yet.
> It seems to me that their intent is to let you jam XML into a field,
> yet select it, search it, etc, as if the XML elements were themselves
> properties of the database table.
> You could then just have an "application types" table that held
the
> XML descriptions of your different categories of
''application'', and an
> ''applications'' table holding the actual instances.
>
> --Wilson.
>
> On 9/27/05, Stephen Caudill
<scaudill-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On 9/27/05, Seth Rasmussen
<seths.mailing.lists-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > I didn''t have to deal with storing the filled out
applications in a
> > > database, though. I simply sent off an email. But perhaps you
could
> > > get away with something like a single applications table that
could
> > > somehow describe which fields were used in an application, and
the
> > > values the user supplied for said fields, without requiring
columns
> > > for every field, of course.
> >
> > Okay, so here''s my stab at it:
> >
> > The structure of the database could be such that each *type* of field
> > (type of question, really, with an associated input element that suits
> > it) that could occur anywhere, in any form is described in a lookup
> > table (perhaps application_line_item_type). An application_line_items
> > table describes each field in a given form by giving a foreign key to
> > the application_line_item_type table and the basic information that is
> > required to customize this field, for instance: (text_field, label,
> > default_value, class, styleid, name)
> >
> > Which supplies enough data to construct a single question on the form.
> > Building an entire application would be consisted of a series of line
> > items all linked by a common FK to the applications table (which
> > consists of id, name and description). To render a form you would
> > join these tables and output the HTML specified by the returned
> > values.
> >
> > Saving the form would another table, answer_line_items which stores
> > user_id, application_line_item_id, application_id and answer.
> >
> > Sound plausible?
> >
> > - Stephen
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
First they laugh at you, then they ignore you, then they fight you.
Then you win.
-- Mahatma Karamchand Gandhi


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Right on. I''m not working on legal applications (or illegal ones), but
it sounds like we''re looking for the same thing.
Clearly the "view generation" stuff is largely a solved problem, via
XML or YAML, though I''m not aware of any Ruby libraries specificially
set up to do this.

However, I think the much trickier problem is finding a way to
represent and store that data in your database.  If the fields aren''t
always the same, how can you make a table with the appropriate columns
in it?

--Wilson.

On 9/29/05, Leon Leslie
<leonleslie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I have a similar problem with the design of a legal application. There are
> over 60 prescribed forms that the public fill out pertaining to events that
> occur in the life of a company.  Example: Register, Notify of a change of
> Secretary, Notify of a Change of Directors, File Mortgages etc...
>
> Filling a particular form will trigger a change in the companies records
> once the information checked and verified.
>
> The application must be able to work against multiple Jurisdictions, which
> have almost the same requirements with small changes in the forms.
>
> It would have been lovely to have some kind of a form builder to create
> custom fields and control meta data in a software application.
>
> Some Desirable features
> --Create Libraries of Questions
> --Conditional branching- Set questions depending on earlier answers
> --Some method of binding actions to model methods
>
> I am interesting in how the community members would have dealt with such a
> problem.
>
> Regards,
> Leon Leslie
>
>
> On 9/28/05, Wilson Bilkovich
<wilsonb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > Interesting idea. I like it.
> > Does anyone have any experience with these so-called XML databases?  I
> > know that there are Oracle features to support this now, but I
haven''t
> > tried them yet.
> > It seems to me that their intent is to let you jam XML into a field,
> > yet select it, search it, etc, as if the XML elements were themselves
> > properties of the database table.
> > You could then just have an "application types" table that
held the
> > XML descriptions of your different categories of
''application'', and an
> > ''applications'' table holding the actual instances.
> >
> > --Wilson.
> >
> > On 9/27/05, Stephen Caudill
<scaudill-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > On 9/27/05, Seth Rasmussen
<seths.mailing.lists-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote:
> > > > I didn''t have to deal with storing the filled out
applications in a
> > > > database, though. I simply sent off an email. But perhaps
you could
> > > > get away with something like a single applications table
that could
> > > > somehow describe which fields were used in an application,
and the
> > > > values the user supplied for said fields, without requiring
columns
> > > > for every field, of course.
> > >
> > > Okay, so here''s my stab at it:
> > >
> > > The structure of the database could be such that each *type* of
field
> > > (type of question, really, with an associated input element that
suits
> > > it) that could occur anywhere, in any form is described in a
lookup
> > > table (perhaps application_line_item_type).  An
> application_line_items
> > > table describes each field in a given form by giving a foreign
key to
> > > the application_line_item_type table and the basic information
that is
> > > required to customize this field, for instance: (text_field,
label,
> > > default_value, class, styleid, name)
> > >
> > > Which supplies enough data to construct a single question on the
form.
> > >  Building an entire application would be consisted of a series of
line
> > > items all linked by a common FK to the applications table (which
> > > consists of id, name and description).  To render a form you
would
> > > join these tables and output the HTML specified by the returned
> > > values.
> > >
> > > Saving the form would another table, answer_line_items which
stores
> > > user_id, application_line_item_id, application_id and answer.
> > >
> > > Sound plausible?
> > >
> > > - Stephen
> > > _______________________________________________
> > > Rails mailing list
> > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > > http://lists.rubyonrails.org/mailman/listinfo/rails
> > >
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
>
>
>
> --
> First they laugh at you, then they ignore you, then they fight you.
> Then you win.
> -- Mahatma Karamchand Gandhi

Wilson Bilkovich wrote:
> Right on. I''m not working on legal applications (or illegal ones),
but
> it sounds like we''re looking for the same thing.
> Clearly the "view generation" stuff is largely a solved problem,
via
> XML or YAML, though I''m not aware of any Ruby libraries
specificially
> set up to do this.
A generator to build the views, actions, controllers and database fields
from a YAML file would be quite nice.  I don''t think it''d be
that
tricky, either...
> However, I think the much trickier problem is finding a way to
> represent and store that data in your database.  If the fields
aren''t
> always the same, how can you make a table with the appropriate columns
> in it?
It''s somewhat less than optimal, but I get around this by having a
table
like:

create table formfields (
	form_id int,
	user_id int, (or whatever)
	key varchar(255),
	value text
);

Whether I bother having an id field in the table depends on whether I
need to treat each data item as a full object, or if I can just
aggregate them cleanly.  This lets you search on values quite happily,
but it''s clearly not the most efficient structure in the world.

Would it be easy to make an acts_as_variant tag for ActiveRecord?  I''m
thinking of being able to do:

class Form << AR::Base
	acts_as_variant :table_name=>''formfields'',
:scope=>''User''
end

and having the values greedily pulled in from the formfields table when
the Form object is loaded.  Has anyone tried this?

-- 
Alex

I like this one...

On 9/29/05, Alex Young <alex-qV/boFbD8Meu8LGVeLuP/g@public.gmane.org>
wrote:
>
> Wilson Bilkovich wrote:
> > Right on. I''m not working on legal applications (or illegal
ones), but
> > it sounds like we''re looking for the same thing.
> > Clearly the "view generation" stuff is largely a solved
problem, via
> > XML or YAML, though I''m not aware of any Ruby libraries
specificially
> > set up to do this.
> A generator to build the views, actions, controllers and database fields
> from a YAML file would be quite nice. I don''t think it''d
be that
> tricky, either...
>
> > However, I think the much trickier problem is finding a way to
> > represent and store that data in your database. If the fields
aren''t
> > always the same, how can you make a table with the appropriate columns
> > in it?
> It''s somewhat less than optimal, but I get around this by having a
table
> like:
>
> create table formfields (
> form_id int,
> user_id int, (or whatever)
> key varchar(255),
> value text
> );
>
> Whether I bother having an id field in the table depends on whether I
> need to treat each data item as a full object, or if I can just
> aggregate them cleanly. This lets you search on values quite happily,
> but it''s clearly not the most efficient structure in the world.
>
> Would it be easy to make an acts_as_variant tag for ActiveRecord?
I''m
> thinking of being able to do:
>
> class Form << AR::Base
> acts_as_variant :table_name=>''formfields'',
:scope=>''User''
> end
>
> and having the values greedily pulled in from the formfields table when
> the Form object is loaded. Has anyone tried this?
>
> --
> Alex
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
First they laugh at you, then they ignore you, then they fight you.
Then you win.
-- Mahatma Karamchand Gandhi


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails