Eric Abrahamsen <e...@ericabrahamsen.net> writes: > "Roland Winkler" <wink...@gnu.org> writes: > >> On Tue May 28 2013 Eric Abrahamsen wrote: >>> Could the organization field, instead of being a string, actually be a >>> link (or a search-string) to a separate record? Then when you display an >>> individual record that links to that organization, there could be a >>> display-only, virtual "work address" shown for that individual. Gets you >>> partway there, anyway. >> >> I guess that a proper solution to this problem could be some sort of >> this kind. But I'd prefer to have such a solution not only for the >> organization field but, say, for addresses too. In any case, "links" >> go beyond the currently supported format of the database file. >> That's why all this goes beyond what is currently possible.
I forgot to add, the whole reason I brought up the below was that, using EIEIO, field instances (an address, for instance) would be independent objects, and could be referenced by slots on multiple records. You could even have record slots pointing to other records, allowing you to create a true representation of a family, or a company. > I once half-jokingly suggested rewriting BBDB to use the EIEIO object > system. The joke part was only because it would be a hell of a lot of > work: actually I think an OO-type system is pretty much ideal for what > BBDB does. Advantages I can think of: > > 1. Probably a much smaller codebase, at least for bbdb.el, also clearer > and easier to maintain. > > 2. You'd get multiple databases (and I think remote databases) for free > with eieio-persistent > > 3. Incoming data checking/cleaning/validation becomes methods on > field classes > > 4. Inheritance of field classes means it becomes very easy for > users to create new kinds of fields > > 5. Printing methods on field types means users can override how existing > fields are displayed in the *BBDB* buffer > > 6. I'm pretty sure those same printing methods could be used to store > text properties and other fancy display stuff along with the data > > 7. Reading/printing methods for the database as a whole would make it > easier to write importers/exporters for BBDB. Database printers could (I > think) also override existing field printers, so users could run an > existing LaTeX exporter (for instance), but just override how some of > the fields were converted to latex. > > 8. It would be easier to attach arbitrary methods to certain field > types, to make them "do things", ie notify a birthday, send an IM, etc. > > It's still more or less pie-in-the-sky, but I think it makes a lot of > sense in principle. > > Eric > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > bbdb-info@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bbdb-info > BBDB Home Page: http://bbdb.sourceforge.net/ ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
