Re: [WebDNA] feature request - .hdr files

This WebDNA talk-list message is from

2011

It keeps the original formatting. numero = 106569
interpreted = N
texte = I developed a system of my own many MANY years ago when I wrote the eCommerce system for Typhoon. I was more or less forced to do this because Typhoon could only open one database, and I wanted to use that one database as if it were several different databases. So I abstracted the field names which started with names like f001, f002, f003, etc., then I added certain letters to the field names to pre-define the kinds of data they would contain. I even used special letters in the field names to define the type of form field each db field might use when appending and replacing ... so I could standardize my form creation dynamically without having to manually specify what type of form field was to be used for each field in the db.The problem with this technique is that as soon as you define how a field must be named, and what characteristics that field must have, someone will whine about not being able to name the fields the way they like, or wanting other characteristics for the field instead of the ones that have been pre-defined.The bottom line here is that I like WebDNA just the way it is. When you use it all the time this issue just never comes up, at least for me.Sincerely,Kenneth Grome> OMG, a 5 year old post of mine, and it's still relevant> :)> > I've been extensively redoing 2 websites in WebDNA over> the last few months, and... Wow, did I write bad code in> the old days, lol. I've come to realize that the> [function] tag is one of the most underutilized tag that> makes WebDNA closer to other programming languages.> > Additionally, after playing with Django (Python) and> Rails (Ruby) one of the things that still irritates me> the most about WebDNA is the primitive handling of the> databases. Specifically the header file.> > example:> > inventory.hdr (webdna)> RID SKU AddDate ModDate ModTime> OnWeb status mfg model > description> > prices.hdr> PID SKU QTY PRICE updated_on> > > > the current header file is just the first title line from> a tab delimited file, stripped out and made into its own> file. What if instead it was totally different, it more> like a Django model:> > > > Inventory.hdr> (id field is implied, you dont need to define it, it's> always the first field of every (database/table) and> always auto incremented for a new record) sku => CharField(max_length=20, db_index=True, unique=True)> created_at = DateTimeField(auto_now_add=True, )> updated_at = DateTimeField(auto_now=True, )> is_public = BooleanField(default=True) #onweb. note> that the pound sign lets you comment a field status => CharField(max_length=8, choices=STATUS_CHOICES,> default="X") mfg = CharField(max_length=100, )> model = CharField(max_length=150)> description = TextField(, blank=True)> > STATUS_CHOICES => ('X', 'Normal'),> ('N', 'New'),> ('C', 'Clearance'),> ('H', 'Showcase'),> ('S', 'Special Order'),> ('R', 'Rebuild'),> ('O', 'Obsolete'),> ('D', 'Discontinued'),> > Price.hdr> (id field is implied, you dont need to define it, it's> always the first field of every (database/table) and> always auto incremented for a new record) product => ForeignKey('Inventory.db')> qty = IntegerField(max_length=11)> price = DecimalField(max_digits=11, decimal_places=2,> blank=True) updated_at => DateTimeField(auto_now_add=True, auto_now=True, )> > > > This would put us a little closer to using "models"> around our data, and help cut down on "webdna isn't a> modern language" arguments, while also cleaning up> significantly our search and append code. It also> allows up to better document (thru comments) reasons why> a field exists or what it is used for, etc. Very handy> for multiple developer projects or projects that run for> years unattended, then need maintenance years later...> > > Brian B. Burton> brian@burtons.com> > "Remember though, it is not the jar that is important but> the empty space inside that is of value."> > On Apr 17, 2011, at 2:55 PM, Govinda wrote:> > Hi Chris> > > > I do respect and really enjoy the rich feature set that> > is webdna.. but we do still need development. I try> > to keep my requests to a practical minimum.. and not> > just complain.> > > > Here is a real need I have had many times in the last> > year: We need a quick way to debug RAM tables. It is> > a slow pain to find an issue when tables are involved.> > Brian described it well here:> > > > http://dev.webdna.us/TalkListArchive/DetailResults.tpl?> > command=search&db=webdna-talk.db&eqIDdata=57773&max=1&w> > ords=ListFields%20table%20bug> > > > Once small quick fix might be to add [Table]s to> > [ListFields]'s capabilities.> > > > - Govinda> > ---------------------------------------------------------> This message is sent to you because you are subscribed to> the mailing list .> To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us> Bug Reporting: support@webdna.us Associated Messages, from the most recent to the oldest:

Re: [WebDNA] feature request - .hdr files (Kenneth Grome 2011)
Re: [WebDNA] feature request - .hdr files ("Brian B. Burton" 2011)

I developed a system of my own many MANY years ago when I wrote the eCommerce system for Typhoon. I was more or less forced to do this because Typhoon could only open one database, and I wanted to use that one database as if it were several different databases. So I abstracted the field names which started with names like f001, f002, f003, etc., then I added certain letters to the field names to pre-define the kinds of data they would contain. I even used special letters in the field names to define the type of form field each db field might use when appending and replacing ... so I could standardize my form creation dynamically without having to manually specify what type of form field was to be used for each field in the db.The problem with this technique is that as soon as you define how a field must be named, and what characteristics that field must have, someone will whine about not being able to name the fields the way they like, or wanting other characteristics for the field instead of the ones that have been pre-defined.The bottom line here is that I like WebDNA just the way it is. When you use it all the time this issue just never comes up, at least for me.Sincerely,Kenneth Grome> OMG, a 5 year old post of mine, and it's still relevant> :)> > I've been extensively redoing 2 websites in WebDNA over> the last few months, and... Wow, did I write bad code in> the old days, lol. I've come to realize that the> [function] tag is one of the most underutilized tag that> makes WebDNA closer to other programming languages.> > Additionally, after playing with Django (Python) and> Rails (Ruby) one of the things that still irritates me> the most about WebDNA is the primitive handling of the> databases. Specifically the header file.> > example:> > inventory.hdr (webdna)> RID SKU AddDate ModDate ModTime> OnWeb status mfg model > description> > prices.hdr> PID SKU QTY PRICE updated_on> > > > the current header file is just the first title line from> a tab delimited file, stripped out and made into its own> file. What if instead it was totally different, it more> like a Django model:> > > > Inventory.hdr> (id field is implied, you dont need to define it, it's> always the first field of every (database/table) and> always auto incremented for a new record) sku => CharField(max_length=20, db_index=True, unique=True)> created_at = DateTimeField(auto_now_add=True, )> updated_at = DateTimeField(auto_now=True, )> is_public = BooleanField(default=True) #onweb. note> that the pound sign lets you comment a field status => CharField(max_length=8, choices=STATUS_CHOICES,> default="X") mfg = CharField(max_length=100, )> model = CharField(max_length=150)> description = TextField(, blank=True)> > STATUS_CHOICES => ('X', 'Normal'),> ('N', 'New'),> ('C', 'Clearance'),> ('H', 'Showcase'),> ('S', 'Special Order'),> ('R', 'Rebuild'),> ('O', 'Obsolete'),> ('D', 'Discontinued'),> > Price.hdr> (id field is implied, you dont need to define it, it's> always the first field of every (database/table) and> always auto incremented for a new record) product => ForeignKey('Inventory.db')> qty = IntegerField(max_length=11)> price = DecimalField(max_digits=11, decimal_places=2,> blank=True) updated_at => DateTimeField(auto_now_add=True, auto_now=True, )> > > > This would put us a little closer to using "models"> around our data, and help cut down on "webdna isn't a> modern language" arguments, while also cleaning up> significantly our search and append code. It also> allows up to better document (thru comments) reasons why> a field exists or what it is used for, etc. Very handy> for multiple developer projects or projects that run for> years unattended, then need maintenance years later...> > > Brian B. Burton> brian@burtons.com> > "Remember though, it is not the jar that is important but> the empty space inside that is of value."> > On Apr 17, 2011, at 2:55 PM, Govinda wrote:> > Hi Chris> > > > I do respect and really enjoy the rich feature set that> > is webdna.. but we do still need development. I try> > to keep my requests to a practical minimum.. and not> > just complain.> > > > Here is a real need I have had many times in the last> > year: We need a quick way to debug RAM tables. It is> > a slow pain to find an issue when tables are involved.> > Brian described it well here:> > > > http://dev.webdna.us/TalkListArchive/DetailResults.tpl?> > command=search&db=webdna-talk.db&eqIDdata=57773&max=1&w> > ords=ListFields%20table%20bug> > > > Once small quick fix might be to add [table]s to> > [listfields]'s capabilities.> > > > - Govinda> > ---------------------------------------------------------> This message is sent to you because you are subscribed to> the mailing list .> To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us> Bug Reporting: support@webdna.us Kenneth Grome

DOWNLOAD WEBDNA NOW!

Re: [WebDNA] feature request - .hdr files

2011

Top Articles:

Related Readings: