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.

> 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.

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'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.

I can understand striving for general solutions to problems, but I've
also seen it go too far to the point where a project sacrifices too
much usability or convenience. I'm not sure if this is such a case or
not, so I won't label it as such, just point out that picking
something that's more general may not always be the best decision. For
instance, we could all be using encrypted free form plain text files
to store our logins/passwords. :) Duplication of data is another
pitfall to avoid, and in this case I think we might be duplicating a
lot of data by forcing any information we'd like applied to a type
into every entry of that type.

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



Devan Goodwin <[EMAIL PROTECTED]>

Reply via email to