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.
<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'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 defined. Cheers, Devan -- Devan Goodwin <[EMAIL PROTECTED]> http://dgoodwin.dangerouslyinc.com
