On Wed, 24 May 2000, Peter Haworth wrote:
> Jeffrey W. Baker wrote:
> > On Wed, 24 May 2000, Peter Haworth wrote:
> > > Jeffrey W. Baker wrote:
> > > > myInput = hfTextInputNew();
> > > > myInput->addAttr(myInput, "name", "first_name");
> > > > myInput->addAttr(myInput, "value", "Jeffrey");
> > > > printf("%s\n", myInput->render(myInput));
> > > > myInput->destroy(myInput);
> > > >
> > > > I would expect a similar interface with more methods for a select box,
> > > > e.g. mySelect->addOption(mySelect, myOption), and myOption->select.
>
> Is this C or C++? If C, do you have a member for each function in the struct,
> and if it's C++, why are you passing myInput twice? Or maybe you just got
> carried away with your example.
It's C with function pointers as struct members.
>
> > > Where do you store those attributes before you do the rendering? If you
> > > tie yourself to Apache, you could use tables. If you tie yourself to perl,
> > > you can use hashes. Otherwise you have to do your own hashes. Blech,
> > > especially if you then use the library with Apache and/or perl - wasted
> > > effort.
> >
> > Actually, there is another way, and that is to simply build a linked list
> > of attributes. It doesn't matter what order you put the attributes in, so
> > I just add them to the head of the list for performance. Adding to the
> > head of a list is faster than hashing anyway. If you use the
> > setAttr(self *, char *, char *) method, the list has to be scanned, but is
> > is likely to be so short as to not matter.
>
> OK, that seems sensible. There's no reason to go overboard to get more
> hash-like semantics, when you'll generally just be stuffing things in, then
> reading them all out.
Exactly. The mainstream use case is to add things and then render. The
capability to remove and change things exists, but doesn't need to be as
streamlined.
> > The other advantage here is storage space. An attribute in this
> > implementation takes up only 4*sizeof(void *) + strlen(name) +
> > strlen(value) + 2.
>
> Is it a doubly linked list, or are you storing something other than name,
> value, next?
Doubly-linked. You aren't sweating those extra 32 bits are you? ;)
>
> > > Bear in mind that it's nice to be able to support arbitrary attributes for
> > > things like onMouseClick and the like, horrible though they are. This
> > > means that you can't just define structs with members dedicated to
> > > specific attributes.
> >
> > Done. The same approach is also used for adding options to a select box,
> > although a select box will have an additional sort() method.
>
> Well, personally, I'd have sorted my options before setting them up. Otherwise
> you need unnecessarily complicated comparison functions to keep your "Please
> select something" option at the top. ALthough, if it works that way, adding
> options to a select has to add to the tail of the list, or you'd have to add
> your options in reverse order.
If the options are sorted before adding, then you just wouldn't call the
sort() method. Or maybe it would be sortByValue() and
sortByLabel(). That sounds more flexible.
-jwb
