V4RB suggestions/feature requests

[Ruslan Zasukhin]

on 4/6/03 7:04 PM, Pedro fp at mail at pedro.Net.au wrote:

Hi Pedro,

> G'day Ruslan
> 
> As I said in my mail to the list I think an optional parameter to
> ImportText, HasHeader As Boolean, with a default value of false, would
> be a great improvement. As it is if a developer wants to accommodate
> files that have headers s/he has to write code to open the file with
> the header, write a new [temp] file that has no header & then pass that
> file to ImportText. Setting a parameter to true when required would be
> a whole lot simpler.

Agree. I know that some DBMS e.g. Access or Excel,
Produce this header line.

> My own application reads the first line of an import file & if all
> fields match field names [or labels which I shall visit later] it is
> taken as a header.
> 
> A similar parameter added to ExportText would make if simpler to export
> files with headers in the same way. Again if it was an optional
> parameter with the default as false it would mean no changes to
> existing developer codes.

Well, agree.

> The labels that I mentioned earlier are another thing I've been wanting
> in some database for years. You may remember a question I put to the
> list about sub-classing vFields. Labels are one of the properties I use
> this for. In every database I have worked with field names that have no
> spaces are easier to program with [e.g. by not having to use quotes
> around them in SQL] but not necessarily end user friendly. So I might
> have a field that I name theUShortField & by using my sub-classes give
> it a label of "The Integer Field" for the benefit of the end user.
> 
> What it amounts to is an additional field property [Label As String]
> that I implement by sub-classing & would like you to add to Valentina.
> Please consider :)

I think this is VERY specific to YOUR app, and it should not be in generic
db engine. 

In the same time I want to point, that I have had idea of EXTENING of
properties for system objects/classes. This idea can be found in Valentina
SQL.pdf where is described system tables.
In fact SQL for system tables still not implemented, so this idea do not
work yet. 
As far as I see, it will allow implement YOUR needs.

> Two other field properties that I use a lot are Searchable As Boolean
> [also implemented in my sub-classes of vFields] & Protected As Boolean.

> The former is used when building a list of fields for user defined
> searches so that fields that make no sense to search by [such as join
> pointers & housekeeping fields] can easily be excluded. The latter is
> used to define whether the end user can modify [or remove] the field.

I see

> I haven't used Protected in my vField sub-classes because [as advised by you
> in answer to one of my list questions] I intend to put all user defined &
> customisable fields in another table that is entirely dynamically defined &
> with a 1 to 1 join to the primary table.
> 
> It may be that these two are particular enough to my needs & the way I
> work that they shouldn't be added to Valentina as they are so I won't
> ask you to add them as I've just described them. [On the other hand
> that I use them as commonly as I do could mean they're more universal
> than I'm giving them credit for.] Instead I'd like to suggest that you
> add 2 or 3 boolean field properties that developers can use [or ignore]
> as they see fit. 

Okay, again, I see as very powerful OO feature for future -- ability to add
properties to BaseObjects/Tables, and to Fields.
This feature will allow developers create own custom types of fields in the
first turn.

> I think that 3 would be plenty but then maybe if you
> provided 3 then some developer would find hirself a use for a 4th.
> Perhaps a boolean array property would be even better, something like
> DevFlags() As Boolean with a default length of 0. If one developer had
> no need for such flags he could just leave it be, if another needed 10
> she could set the array length to 10. In fact this would be even more
> flexible than a fixed number of DevFlags because the number of flags
> could be set field by field.
> 
> Another advantage of providing such flags [& field labels] as vField
> properties is that then that data has a natural home. In most of my
> implementations I have created a global prefs table that has one record
> and all my extra field properties are stored in a field of that. Then I
> make loading the extra properties one of the first tasks on opening of
> the database.
> 
> From what I've learned reading you on the list I think these ideas fit
> well with your philosophy in these matters. I hope my thoughts prove
> useful in making Valentina an even better database engine than it
> already is.

Thank you for ideas.

Let's hope 2.0 will include this features.

-- 
Best regards,
Ruslan Zasukhin      [ I feel the need...the need for speed ]
-------------------------------------------------------------
e-mail: ruslan at paradigmasoft.com
web: http://www.paradigmasoft.com

To subscribe to the Valentina mail list go to:
http://listserv.macserve.net/mailman/listinfo/valentina
-------------------------------------------------------------