(I sent a separate email describing the current plans for account types
in more detail, please read that before reading this response)
On Wed, 2007-02-21 at 23:57 -0400, Devan Goodwin wrote:
> On 2/21/07, Travis Snoozy <[EMAIL PROTECTED]> wrote:
> > Search, then bulk-change the results. That should totally be a feature,
> > regardless of whether templates are used or not.
> What would you search on? Entries are now disjoint from their template
> or type, unless you imagine using a tag, but that could return many
> results not related unless you expect users to enforce a "tag == type"
> mentality in their day to day use. I tend to think of tags as subject
> matter related, and not as a type.
Agreed. Using tags to store the account type is the Wrong Thing to do.
First, by even implying the idea you admit that there is such a thing as
an "account type" in the real world, and if our data model does not
reflect this then that model does not correctly represent what we are
trying to describe. Also, you are now describing two different pieces of
data (account type and keywords) in the same field, which is a big no-no
in data modelling as it has all kinds of bad consequences.
> > <snip>
> > > Both of these are quite serious usability issues, and I'd say these
> > > alone are reason enough to keep a link between the accounts and the
> > > account type.
> > <snip>
> > You'll have this issue anyway, with custom accounts. I think that going
> > to completely generic accounts with some default templates is the way
> > to go.
> User modifies their custom account type, all affiliated entries are
> updated. Not sure what you mean when you say this issue will exist
> either way?
It is true that you will still have this issue, but to a much, much
lesser degree. Any account can be a custom account by adding or removing
fields from the default set of fields provided by the account type. But
in that case you are intentionally saying that this field is an
exception from most other accounts, and so it should be handled like
As for launchers, you will be able to define launchers that override the
default - but again, in that case this is an exception for this single
account, and so should be handled as one (ie, no auto-updating etc).
> > It's just a matter of developing the right tool set to work with the
> > data. Having everything be template-based is waaaay more elegant and
> > extensible, and this will make the code way simpler to deal with
> > (there are no "special" code branches for specific types of accounts).
> > You don't lose any of the benefits of having "hard" account types --
> > you just have to think about things in a slightly different way, and
> > all of the functionality is present and accounted for. If you can't
> > tell, I'm a big fan of having things be data-driven. :)
> I expect there won't be any account type specific code branches once
> the current work towards custom account types is complete.
True - there will be no hard-coded account types (except for a default
set provided when creating a new file), and there will be no separate
code-paths for specific account types. It will be completely
data-driven, and I don't know why one would have the impression that
this is not possible with account types.
> In my mind I see just one small benefit to severing the relationship
> (one-off's), and many downsides that will affect the use of that data
> through it's lifetime. I think my preference would remain to have the
> entries affiliated with their types. My one-off needs are slim and
> easily remedied by a notes field, or by Revelation knowing how to
> interpret and display extra entry fields that it's type doesn't have
Exactly, the comments I've seen so far doesn't mention any kind of
functionality that would not be possible with the new account type
Erik Grinaker <[EMAIL PROTECTED]>
"We act as though comfort and luxury were the chief requirements of
life, when all that we need to make us happy is something to be
-- Albert Einstein