Re: [Apc-aa-coders] IDS - maybe a change to make - lets discuss

[Honza M. <hon...@ec...>]

On =DAt, 2003-01-14 at 07:22, Zoltan Varady wrote:

> > I would suggest we need two classes, "id" for handling a single id,=20
> > and "idarray"  for handling arrays of ids?  The interface should=20
> > allow for returning results directly from an "idarray" WITHOUT=20
> > neccessarily instantiating an "id" for example:
> >
> > $url .=3D $myid->longid; to return the long id .
> > OR
> > $url .=3D $myarray->longid(10); to return the long id of the 10th id =
in=20
> > the array
> >
> > but not requiring
> > $url .=3D $myarray->id(10)->longid.
> >
> > Am i on the right direction?
>=20
> Sounds great!=20

Yes. Only inner implementation of "idarray" will not be array of "id"
objects, because it is probably not memory efficient.

> I also saw it as a problem that we have all these=20
> different types of ID's. What is the reason for this, is it historical?=
=20

Yes, historical reasons.

> Shouldn't just short ID's be enough?

Yes, we can use short_ids as much as possible. The new fetures could be
based on short_ids.

> Or do we need long ID's for portability and feeding between databases?

It is easier, but not necessary to use long ids. On the other hand, we
already use it and who have the time to rewrite the code.

> I suppose the difference between quoted packed and unquoted packed is=20
> that any character can appear in a packed ID, even quotes, so you need=20
> to addslashes and stripslashes...

Yes - quoted for storing into database or not.

> Maybe we could do something similar with slice ID's (packed, unpacked,=20
> quoted, unquoted), and field names (packed, unpacked....)?

For slice ids we can use the same class - it is exactly the same as item
ids.

Field names we allways use in unpacked - 16 character long form.

> I also think this is important because it makes the programming=20
> interface clearer. During my work for FoEI (I'm just finishing now) we=20
> tried using APC-AA as a back-end for storing data, and we used a=20
> different template engine, we haven't used the fulltext view, index=20
> view, etc. directly. Looking back, I'm not sure that this was a good=20
> idea, but in the future I'd like to create a kind of API to APC-AA, so=20
> that it could interoperate more easily with external PHP code. This=20
> looks like a step in that direction.

Sounds good. Please consult the API before you will do it. We found very
usefull to have only one way, how to get items from database
(QueryIDs(), GetItemContent()). The database changes and new feature
implementation (like password protected items, ...) are much easier with
one set of functions used.

> BTW one more thing: is there a specific reason why field names _must_=20
> be 16 (or however many) characters long? And do they have to have the=20
> name.............3 syntax with the dots? It annoys me, because whenever=
=20
> I need to put the headline field into an inline alias, for example,=20
> whenever I need to type the field name, I have to copy & paste it from=20
> the "fields" section of the admin interface - I cannot just type=20
> "headline.........." because I will surely screw up the number of dots.=
=20
> Can't field names be just normal names like "headline",=20
> "uploaded_image", or whatever?

Yes, it is 16 character long - exactly. When we do it, we don't think
users will ever write the field ids. Now they do. The id consist of
field type, counter and dots between. We use the id to get type of field
on some (not so many) spots - mainly for 'category' field. I think we
should not change the field ids - we rather have to think about some
alternative shortcuts (like headline.......2 =3D headline-2 or such).

   Honza

>=20
>=20
> 	cheers!
>=20
> 	Zoltan.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Apc-aa-coders mailing list
> Apc...@li...
> https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>=20