I''ve got a real estate site that I''m trying to transition to rails. Currently, they enter 3 columns of date for each listing. This information isn''t always the same, but they do care what order it is in and they want to make sure all 3 columns are equal in length or real close at least. example: DESC: 3-2-2 LOCATION: Arlington/76M TYPE: Traditional LOT SIZE: 1 acres BD #1: 11x14 FENCE: Privacy etc.... Currently I use 3 textareas and use the carriage return to split up the elements so that they can be displayed in a table. Is this same kind of thing doable in RoR? Thanks -- Marlon "A mulatto, an albino, a mosquito, my libido"
Use the date helper: http://api.rubyonrails.com/classes/ActionView/Helpers/DateHelper.html -Jeff ----- Original Message ----- From: "Marlon Moyer" <marlon.moyer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> Sent: Wednesday, August 17, 2005 3:43 PM Subject: [Rails] How would you do this? I''ve got a real estate site that I''m trying to transition to rails. Currently, they enter 3 columns of date for each listing. This information isn''t always the same, but they do care what order it is in and they want to make sure all 3 columns are equal in length or real close at least. example: DESC: 3-2-2 LOCATION: Arlington/76M TYPE: Traditional LOT SIZE: 1 acres BD #1: 11x14 FENCE: Privacy etc.... Currently I use 3 textareas and use the carriage return to split up the elements so that they can be displayed in a table. Is this same kind of thing doable in RoR? Thanks -- Marlon "A mulatto, an albino, a mosquito, my libido" _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Uh... I think the word "date" there was a typo. Jeffrey Moss wrote:> Use the date helper: > > http://api.rubyonrails.com/classes/ActionView/Helpers/DateHelper.html > > -Jeff > > > > I''ve got a real estate site that I''m trying to transition to rails. > Currently, they enter 3 columns of date for each listing. This > information isn''t always the same, but they do care what order it is > in and they want to make sure all 3 columns are equal in length or > real close at least.
Oh, well in that case Marlon, impress your client with Tom Mack''s sortable tables script for prototype. The spacing issue is all html-land, just use td width="30%" http://www.tom-mack.com/tablesort/ -Jeff ----- Original Message ----- From: "Matt Powell" <matt-aUjHfZsTZX9iql55EdJREXTaI6DYlTYJ@public.gmane.org> To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> Sent: Wednesday, August 17, 2005 3:54 PM Subject: Re: [Rails] How would you do this?> Uh... I think the word "date" there was a typo. > > Jeffrey Moss wrote: >> Use the date helper: >> >> http://api.rubyonrails.com/classes/ActionView/Helpers/DateHelper.html >> >> -Jeff >> >> >> >> I''ve got a real estate site that I''m trying to transition to rails. >> Currently, they enter 3 columns of date for each listing. This >> information isn''t always the same, but they do care what order it is >> in and they want to make sure all 3 columns are equal in length or >> real close at least. > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Oh yeah, I did have a typo there. I was scratching my head wondering how the date helper was going to solve it :) On 8/17/05, Matt Powell <matt-aUjHfZsTZX9iql55EdJREXTaI6DYlTYJ@public.gmane.org> wrote:> Uh... I think the word "date" there was a typo. > > Jeffrey Moss wrote: > > Use the date helper: > > > > http://api.rubyonrails.com/classes/ActionView/Helpers/DateHelper.html > > > > -Jeff > > > > > > > > I''ve got a real estate site that I''m trying to transition to rails. > > Currently, they enter 3 columns of date for each listing. This > > information isn''t always the same, but they do care what order it is > > in and they want to make sure all 3 columns are equal in length or > > real close at least. > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Marlon "A mulatto, an albino, a mosquito, my libido"
I''m actually trying to figure out how to get the information entered in first....Now, if there was a table type of entry, that would be really cool. On 8/17/05, Jeffrey Moss <jeff-61uStg5MtoFWk0Htik3J/w@public.gmane.org> wrote:> Oh, well in that case Marlon, impress your client with Tom Mack''s sortable > tables script for prototype. The spacing issue is all html-land, just use > td width="30%" > > http://www.tom-mack.com/tablesort/ > > -Jeff > > ----- Original Message ----- > From: "Matt Powell" <matt-aUjHfZsTZX9iql55EdJREXTaI6DYlTYJ@public.gmane.org> > To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> > Sent: Wednesday, August 17, 2005 3:54 PM > Subject: Re: [Rails] How would you do this? > > > > Uh... I think the word "date" there was a typo. > > > > Jeffrey Moss wrote: > >> Use the date helper: > >> > >> http://api.rubyonrails.com/classes/ActionView/Helpers/DateHelper.html > >> > >> -Jeff > >> > >> > >> > >> I''ve got a real estate site that I''m trying to transition to rails. > >> Currently, they enter 3 columns of date for each listing. This > >> information isn''t always the same, but they do care what order it is > >> in and they want to make sure all 3 columns are equal in length or > >> real close at least. > > > > _______________________________________________ > > 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 >-- Marlon "A mulatto, an albino, a mosquito, my libido"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You might want to spend some time digging through the http://
trimpath.com/project/wiki/TrimSpreadsheet which is open source and
powers http://numsum.com/
George
- --
George Hotelling GPG: 0x8175D485 ]
http://george.hotelling.net ]
_ _ _ ___ _ _ _/
On Aug 17, 2005, at 7:51 PM, Marlon Moyer wrote:
> I''m actually trying to figure out how to get the information
entered
> in first....Now, if there was a table type of entry, that would be
> really cool.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDA/QRgXVRXIF11IURAr2lAKC8pKiJnx8Beb/tihjs0X8bTjUC5gCgupkK
zlirBBShZ61koz4WHVQA+hw=iPnG
-----END PGP SIGNATURE-----
> Currently I use 3 textareas and use the carriage return to split up > the elements so that they can be displayed in a table. Is this same > kind of thing doable in RoR?I''m not clear. As a user, I would be confused about it being 3 text areas -- what do I enter in each one, which is the correct order for fields, etc. Are all these fields stored as a single string (or 3 strings) in an SQL database, is it being read from a text file, or ? How would I do it? I would split it into a form with each of the fields in the desired order, and clearly show which ones are optional: DESC: [input field] LOCATION: [input field] TYPE: [input field or select/combo box] LOT SIZE: [input field] etc... This would be the screen for adding a new record or editing an existing record. It could be layed out as a 3 column table, but we don''t know which fields the user won''t be filling out so I''d be displaying all of the fields. If the existing data isn''t stored this way I''d write an import script to get into the SQL database in the correct format. (create sample database in mySQL, fill in some values, and export it to see the format to use to import). NOW onto "3 column view": When the user selects ''view'' (different than ''edit'') to see an individual record you can use Ruby/Rails to append the fields that are present for the current record into three different fields (text area) and display them. If you wanted the 3 column view when viewing the list of various listings, then you''d modify the code for ''list'' instead of ''view''. Maybe a link to the existing site would get you better feedback?
Jason wrote:> I''m not clear. As a user, I would be confused about it being 3 text > areas -- what do I enter in each one, which is the correct order for > fields, etc. Are all these fields stored as a single string (or 3 > strings) in an SQL database, is it being read from a text file, or ?+1 Marlon, from what I seem to be understanding from your original posting, it really sounds like the database is totally unsuitable for the data it''s modeling. Instead of bundling everything into these three non-representative fields, I would redesign the database with more sensible fields to store each item of data properly. So instead of your three "huh?" text areas: DESC: 3-2-2 LOCATION: Arlington/76M TYPE: Traditional LOT SIZE: 1 acres BD #1: 11x14 FENCE: Privacy I would suggest something (in the database, and I''m assuming MySQL, although actually I''ve only used Rails with PostgreSQL) more like: CREATE TABLE `estates` ( `id` int(11) unsigned NOT NULL auto_increment, `description` varchar(10), `location` varchar(255), `type` varchar(10), `lot_size` varchar(10), `bedroom1` varchar(10), `fence` varchar(10), `notes` longtext, PRIMARY KEY (`id`), ); Add as many fields as you''re likely to need (eg. bedroom2, bedroom3 and so on), but keep things in their own fields, and use a more appropriate type than varchar (eg. integer, date) where the data can be better represented. The notes column is for anything extra that can''t be represented in the fields predefined in the database. As a general rule, I would say it''s extremely unwise to design your database based on what the output of the data needs to look like! Get the database right, then worry about how you will display the information. If the output order of the fields is important, you can do this in your Rails views, and as for the 3 columns of approximately the same height - again, once you''ve put the data in the desired order, you could either count the fields in each column and shift them around a bit before you output them, or (my preference) use some neat CSS to just get them to form a multi-column layout when displayed. You''ll definitely need to find a way to get the existing data into the new database, but it shouldn''t be too hard, and will no doubt help you build up your column list for the table. I hope you can see why the current system is unwise though, because ultimately if we aren''t going to bother with storing things in the appropriate structures in the database, we might as well just make each table one giant longtext field, with no form of data validation at all, and be done with it. Or, look at it this way: why on earth would you want to re-type and store the column names each time you put an entry into the database? That''s what the database is there for! I''m not meaning to cause any offense here, but perhaps it might be a good idea for you to read a few books or tutorials on good database design principles? I''m hardly a database guru, but the fact that you wanted to continue their existing highly unsuitable system into Rails would suggest that you could do with brushing up your database skills a bit before ploughing headlong into Rails and shooting yourself in the foot. If you''re transitioning a site into Rails, the least you could do would be to improve a crazy database schema as part of the process, and you just can''t afford to think about data based on "what it looks like", because data has no inherent visual appearance - it''s just data! That''s what views are for. I would hazard a guess that you''ll struggle to grasp MVC (and hence Rails) without understanding the above concepts first. If you need some more pointers or get stuck, don''t be afraid to ask! However, I''d suggest you start by Googling "database design principles" and take it from there. Again, sorry if I cause any offense Marlon, it''s just that from the questions you asked, I think it''s safe to say you need a bit of a brush-up on your database design skills before tackling Rails. All the best, ~Dave -- Dave Silvester Rent-A-Monkey Website Development Web: http://www.rentamonkey.com/
On 18.8.2005, at 09:16, Dave Silvester wrote:> Jason wrote: >> I''m not clear. As a user, I would be confused about it being 3 text >> areas -- what do I enter in each one, which is the correct order for >> fields, etc. Are all these fields stored as a single string (or 3 >> strings) in an SQL database, is it being read from a text file, or ? > > +1 > > Marlon, from what I seem to be understanding from your original > posting, it really sounds like the database is totally unsuitable for > the data it''s modeling. Instead of bundling everything into these > three non-representative fields, I would redesign the database with > more sensible fields to store each item of data properly. > > So instead of your three "huh?" text areas: > > DESC: 3-2-2 LOCATION: Arlington/76M TYPE: > Traditional > LOT SIZE: 1 acres BD #1: 11x14 FENCE: > Privacy+100 Marlon: In the current schema, how would you search for properties that are between 2 and 3 acres? Or, get properties that are larger than 4 acres but not traditional. I wouldn''t want to be the one who needs to write the SQL queries for these. There''s a reason why relational databases are designed like they are (or should be). Please follow Dave''s advice and read a good book or two on the subject. It won''t be that hard (I promise), but it will be of immense help in the long run. //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 8/17/05, Marlon Moyer <marlon.moyer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Currently I use 3 textareas and use the carriage return to split up > the elements so that they can be displayed in a table. Is this same > kind of thing doable in RoR?Marlon, While I agree with others who suggest you redo your database to track each of those attributes as separate entities, to answer your question: Yes, what you describe above is certainly possible, and very easy, in Rails. It might be a quick first step just to get all your existing data running in your Rails app. The basic scaffolding code will pretty much get you want you want. Just have those three TEXT fields in your database, generate your Property model and the scaffolding for it. Then take a look at the generated scaffolding code. You can rearrange things to be in the layout you prefer (just put three fields into a table, as I assume they are in your current app). - Isaac
Hi Dave, Thanks for the help and no offense has been taken :) I''m not certain that I''ve communicated the problem correctly. I do have a database set up with information such as the #of bedrooms, # of baths, lot size, etc. I''ve got all the fields set up that would make sense to search across. I don''t believe the search implementation will be problem. The problem I''m trying to find a solution for is demonstrated by these pages: http://www.bettyfry.com/Listings/lochngreen_538/listing.html http://www.bettyfry.com/Listings/larkwood_9/listing.html The data in the table is more for display than searching. Some fields are there, others aren''t. Some fields are filled in, but they don''t need to be displayed, or some fields need to display something different than what they actually are. To the realtor, it looks better for a "Lot size" on a townhome to be "Generous" instead of .2 acres. The realtor wants to have full control over how the information is presented. "Description" is typically the first field displayed, but on a 2 bedroom 1 bath, that''s not even something you want displayed from a marketing standpoint. "LOT SIZE: Almost an acre" looks better than .89 acres. So really, I''m trying to figure out a way that the realtor could enter this information in conveniently. Typically in the past, I might have put up fckeditor and had them enter this in as HTML. I thought that putting 3 textareas formatted like cols="20" rows="10" eg. ------------------ ----------------------- ----------------------- |attr1 | |attr1c2 | |attr1c3 | |attr2 | |attr2c2 | |attr2c3 | |attr3 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------ ----------------------- ----------------------- I was hoping that this format would make it easier for them to enter the ''display'' information. I''ve noticed that some clients can really muck up a site when given free reign with an inline html editor. Also, I thought that I might be able to create an xml structure from the 3 textareas whick I could then use an xslt on to format it into whatever form I need. Thanks for the help. On 8/18/05, Dave Silvester wrote:> Jason wrote: > > I''m not clear. As a user, I would be confused about it being 3 text > > areas -- what do I enter in each one, which is the correct order for > > fields, etc. Are all these fields stored as a single string (or 3 > > strings) in an SQL database, is it being read from a text file, or ? > > +1 > > Marlon, from what I seem to be understanding from your original posting, it > really sounds like the database is totally unsuitable for the data it''s > modeling. Instead of bundling everything into these three non-representative > fields, I would redesign the database with more sensible fields to store each > item of data properly. > > So instead of your three "huh?" text areas: > > DESC: 3-2-2 LOCATION: Arlington/76M TYPE: Traditional > LOT SIZE: 1 acres BD #1: 11x14 FENCE: Privacy > > I would suggest something (in the database, and I''m assuming MySQL, although > actually I''ve only used Rails with PostgreSQL) more like: > > CREATE TABLE `estates` ( > `id` int(11) unsigned NOT NULL auto_increment, > `description` varchar(10), > `location` varchar(255), > `type` varchar(10), > `lot_size` varchar(10), > `bedroom1` varchar(10), > `fence` varchar(10), > `notes` longtext, > PRIMARY KEY (`id`), > ); > > Add as many fields as you''re likely to need (eg. bedroom2, bedroom3 and so > on), but keep things in their own fields, and use a more appropriate type than > varchar (eg. integer, date) where the data can be better represented. The > notes column is for anything extra that can''t be represented in the fields > predefined in the database. > > As a general rule, I would say it''s extremely unwise to design your database > based on what the output of the data needs to look like! Get the database > right, then worry about how you will display the information. > > If the output order of the fields is important, you can do this in your Rails > views, and as for the 3 columns of approximately the same height - again, once > you''ve put the data in the desired order, you could either count the fields in > each column and shift them around a bit before you output them, or (my > preference) use some neat CSS to just get them to form a multi-column layout > when displayed. > > You''ll definitely need to find a way to get the existing data into the new > database, but it shouldn''t be too hard, and will no doubt help you build up > your column list for the table. > > I hope you can see why the current system is unwise though, because ultimately > if we aren''t going to bother with storing things in the appropriate structures > in the database, we might as well just make each table one giant longtext > field, with no form of data validation at all, and be done with it. > > Or, look at it this way: why on earth would you want to re-type and store the > column names each time you put an entry into the database? That''s what the > database is there for! > > I''m not meaning to cause any offense here, but perhaps it might be a good idea > for you to read a few books or tutorials on good database design principles? > I''m hardly a database guru, but the fact that you wanted to continue their > existing highly unsuitable system into Rails would suggest that you could do > with brushing up your database skills a bit before ploughing headlong into > Rails and shooting yourself in the foot. > > If you''re transitioning a site into Rails, the least you could do would be to > improve a crazy database schema as part of the process, and you just can''t > afford to think about data based on "what it looks like", because data has no > inherent visual appearance - it''s just data! That''s what views are for. > > I would hazard a guess that you''ll struggle to grasp MVC (and hence Rails) > without understanding the above concepts first. > > If you need some more pointers or get stuck, don''t be afraid to ask! However, > I''d suggest you start by Googling "database design principles" and take it > from there. > > Again, sorry if I cause any offense Marlon, it''s just that from the questions > you asked, I think it''s safe to say you need a bit of a brush-up on your > database design skills before tackling Rails. > > All the best, > > ~Dave > > -- > > Dave Silvester > Rent-A-Monkey Website Development > Web: http://www.rentamonkey.com/ > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Marlon "A mulatto, an albino, a mosquito, my libido"
> http://www.bettyfry.com/Listings/lochngreen_538/listing.html > http://www.bettyfry.com/Listings/larkwood_9/listing.html > > The data in the table is more for display than searching. Some > fields are there, others aren''t. Some fields are filled in, but they > don''t need to be displayed, or some fields need to display something > different than what they actually are.This is really a pure presentation issue, it seems to me. You don''t want to do that textarea thing, IMHO. You don''t need to collect formatting informatin from the users, just the data itself. It sounds like the list of potential fields (Age, Location, Schools, Style, etc.) is long but not unknown, so users should input that via a traditional form. Just make two things clear: which fields are optional and which are required, and that the information will be displayed in three roughly equivalent collums. Actually, I''m not sure if the site''s goal was "no matter how many attributes are given, spread them accross three collumns", or if it''s "make sure that the user inputs exaclty 27 peices of information, no matter what those attributes are." The first one is reasonable, the second seems kind of random to me. If the users absolutely need to see the final result up front, it would be neat if you could show a live preview of the presentation as the user fills out the form. Even some static samples of the presentation could illustrate it for the users.
Isaac, how would I take those 3 textareas and create 1 db field with them, that''s really what I''d like to do. Thanks Marlon On 8/18/05, Isaac Reuben <ireuben-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 8/17/05, Marlon Moyer <marlon.moyer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Currently I use 3 textareas and use the carriage return to split up > > the elements so that they can be displayed in a table. Is this same > > kind of thing doable in RoR? > > Marlon, > > While I agree with others who suggest you redo your database to track > each of those attributes as separate entities, to answer your > question: Yes, what you describe above is certainly possible, and very > easy, in Rails. It might be a quick first step just to get all your > existing data running in your Rails app. > > The basic scaffolding code will pretty much get you want you want. > Just have those three TEXT fields in your database, generate your > Property model and the scaffolding for it. Then take a look at the > generated scaffolding code. You can rearrange things to be in the > layout you prefer (just put three fields into a table, as I assume > they are in your current app). > > - Isaac > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Marlon "A mulatto, an albino, a mosquito, my libido"
On 18.8.2005, at 17.36, Marlon Moyer wrote:> Hi Dave, > > Thanks for the help and no offense has been taken :) > > I''m not certain that I''ve communicated the problem correctly. I do > have a database set up with information such as the #of bedrooms, # of > baths, lot size, etc. I''ve got all the fields set up that would make > sense to search across. I don''t believe the search implementation > will be problem. The problem I''m trying to find a solution for is > demonstrated by these pages: > > http://www.bettyfry.com/Listings/lochngreen_538/listing.html > http://www.bettyfry.com/Listings/larkwood_9/listing.html > > The data in the table is more for display than searching.Sorry, I''m a bit slow today. But if the data is stored in the database, why do the realtors fill it to a textarea by hand? Why isn''t it just fetched from the db and presented as you please?> > So really, I''m trying to figure out a way that the realtor could enter > this information in conveniently. Typically in the past, I might have > put up fckeditor and had them enter this in as HTML. I thought that > putting 3 textareas formatted like cols="20" rows="10" eg.I''m with Andrew here. Why on earth would they enter this info as a big chunk if you store it in distinct database fields anyway? Just make a big honkin'' form that they can fill in, and perhaps give them the option to select (e.g. with a checkbox) which data are shown on the page. Again, a preview would be a killer.> I was hoping that this format would make it easier for them to enter > the ''display'' information. I''ve noticed that some clients can really > muck up a site when given free reign with an inline html editor. > Also, I thought that I might be able to create an xml structure from > the 3 textareas whick I could then use an xslt on to format it into > whatever form I need.That would hardly be the simplest thing possible. Sorry if I''ve misunderstood you, but I still feel you''re approaching this from a slightly wrong angle. //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
To do that, define the three text fields as attributes of your ActiveRecord model, but don''t put them in your database table. Then write some code that combines them and plugs them into the field that''s based on the actual column in the table, probably in the "before_save" callback. Marlon Moyer wrote:> Isaac, how would I take those 3 textareas and create 1 db field with > them, that''s really what I''d like to do. > > Thanks > > Marlon > > On 8/18/05, Isaac Reuben <ireuben-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >>On 8/17/05, Marlon Moyer <marlon.moyer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >>>Currently I use 3 textareas and use the carriage return to split up >>>the elements so that they can be displayed in a table. Is this same >>>kind of thing doable in RoR? >> >>Marlon, >> >>While I agree with others who suggest you redo your database to track >>each of those attributes as separate entities, to answer your >>question: Yes, what you describe above is certainly possible, and very >>easy, in Rails. It might be a quick first step just to get all your >>existing data running in your Rails app. >> >>The basic scaffolding code will pretty much get you want you want. >>Just have those three TEXT fields in your database, generate your >>Property model and the scaffolding for it. Then take a look at the >>generated scaffolding code. You can rearrange things to be in the >>layout you prefer (just put three fields into a table, as I assume >>they are in your current app).
On 8/18/05, Jarkko Laine <jarkko-k1O+Gnc6WpmsTnJN9+BGXg@public.gmane.org> wrote:> > > The data in the table is more for display than searching. > > Sorry, I''m a bit slow today. But if the data is stored in the database, why > do the realtors fill it to a textarea by hand? Why isn''t it just fetched > from the db and presented as you please? >For instance, the lot size may be .95 acres and this is stored in the database as an number, but the realtor wants it to say "Almost an acre" on the listing sheet. What I''m doing is giving the realtor free reign to advertise the property the way they want to. There are a lot of fields in that table that will never be searched, but are there only to advertise something. There is a database that holds all relevant, searchable information for this property, but the realtor wants functionality where they can choose what is displayed and how it''s displayed. So, even though some of these fields correlate with fields in the database, they might not reflect the same content. Really, this table is no different than the paragraph below it. It''s marketing speak. I store the paragraph below it in a text field in the database. I also think that it''s perfectly reasonable to store this "content" in a text field in the database.> > > So really, I''m trying to figure out a way that the realtor could enter > this information in conveniently. Typically in the past, I might have > put up fckeditor and had them enter this in as HTML. I thought that > putting 3 textareas formatted like cols="20" rows="10" eg. > > I''m with Andrew here. Why on earth would they enter this info as a big chunk > if you store it in distinct database fields anyway? Just make a big honkin'' > form that they can fill in, and perhaps give them the option to select (e.g. > with a checkbox) which data are shown on the page. Again, a preview would be > a killer. >This would work if they didn''t want to have alternate information in the fields ie exact (database field) :INTERIOR: 3200s.q. marketing speak: INTERIOR: Spacious Plus, right now, the realtor enters all of this information into the MLS system that most realtors use. When you look at listings on the MLS site, you can tell they''ve been generated by a database backend. The information is always in the same place and has the same form. This realtor wants her listings to look like they were custom made by hand.> > I was hoping that this format would make it easier for them to enter > the ''display'' information. I''ve noticed that some clients can really > muck up a site when given free reign with an inline html editor. > Also, I thought that I might be able to create an xml structure from > the 3 textareas whick I could then use an xslt on to format it into > whatever form I need. > > That would hardly be the simplest thing possible. > > Sorry if I''ve misunderstood you, but I still feel you''re approaching this > from a slightly wrong angle. > > //jarkko > > > > > > -- > > Jarkko Laine > > http://jlaine.net > > http://odesign.fi > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > >-- Marlon "A mulatto, an albino, a mosquito, my libido"
In that case, why not do the following: - give users a form where they can enter in the 0.95 acres, etc. (i.e. the objective data about the property) - include an optional text field where agents can enter their marketing spiel (e.g. "This fine property is almost an acre in size, and won''t last long in the present market") When presenting info about the property, if the "marketing spiel" field has data in it, that''s what you present. If it''s empty, you produce some pre-canned, computer generated text that includes all the relevant information (e.g. "This property is 0.95 acres in size, has 4 bedrooms and 2 bathrooms...") That gives you the best of both worlds: customised marketing info if the agent cares to enter that information, or pre-canned text if not. Regards Dave M.> For instance, the lot size may be .95 acres and this is stored in the > database as an number, but the realtor wants it to say "Almost an > acre" on the listing sheet. What I''m doing is giving the realtor free > reign to advertise the property the way they want to. There are a lot > of fields in that table that will never be searched, but are there > only to advertise something. There is a database that holds all > relevant, searchable information for this property, but the realtor > wants functionality where they can choose what is displayed and how > it''s displayed. So, even though some of these fields correlate with > fields in the database, they might not reflect the same content. > > Really, this table is no different than the paragraph below it. It''s > marketing speak. I store the paragraph below it in a text field in > the database. I also think that it''s perfectly reasonable to store > this "content" in a text field in the database. >(snip)> > Plus, right now, the realtor enters all of this information into the > MLS system that most realtors use. When you look at listings on the > MLS site, you can tell they''ve been generated by a database backend. > The information is always in the same place and has the same form. > This realtor wants her listings to look like they were custom made by > hand. > >