Current Best Practices

[hypercardjdowns]

I'm developing a tool to track my daily work, like a planner/journal. None of the commercially available options meet my needs.

What is the current best practice on something like this? Are folks using SQL databases to retain what is essentially simple text records? Or does the community still use the old HyperCard methodology with a card per date? Something else?

Thanks,
J.

[bogs]

I don't know that it would be a 'best practice' type of question, as much as a 'personal preference'. I think it would really depend on just what you need out of it.

Just to throw another banana in your path, you forgot another alternative, 1 (or more) flat-files. In fact, if you made the name the date, it would be self chronologically ordering and provide easy look up, and at a couple kb a file, probably smaller than the sqlite solution

(Just make sure you use a LONG year format of 4 digits

[hypercardjdowns]

Just to throw another banana in your path, you forgot another alternative, 1 (or more) flat-files. In fact, if you made the name the date, it would be self chronologically ordering and provide easy look up, and at a couple kb a file, probably smaller than the sqlite solution :D

(Just make sure you use a LONG year format of 4 digits :twisted:

Thanks for this. Had not occurred to me, and this is an even better solution, as the rest of my notes exist as simple text files. Do folks usually stick with an XML format when creating such files?

[bogs]

Well again, it would be a personal preference thing. Myself, I've never ever used xml for anything (had already stopped developing web pages before it came along really).

I can't think off the top of my head of any benefit to complicating something *IF* it is simple to begin with. If it isn't simple to begin with, maybe it needs to be rethought, or, you might have a good case for xml.

Lots like it, lots don't, toss a quarter and see if it hits heads or tails

[jmburnod]

Hi,

Do folks usually stick with an XML format when creating such files?

I use text files with item delimiter. Simple, flexible and lisible
Best
Jean-Marc

[FourthWorld]

Like Jean-Mark, I often use tab-delimited text files. When hierarchical ordering is needed, I use LSON files (encoded arrays). Sometimes a mix. Sometimes a DB.

Storage options are plentiful. I'm not sure there is a single "best" practice, except maybe the one that best fits the problem at hand.

[dunbarx]

I always say that unless there is a compelling reason to go outside LC, external files, databases, whatever, don't.

I am blinkered and small-minded this way. I am almost always right. Did I mention I was small-minded and blinkered?

The general scope of what you are thinking about seems to me so easily implemented inside LC, that it is a no-brainer.

Did I mention I had no brains?

Craig

[hypercardjdowns]

I always say that unless there is a compelling reason to go outside LC, external files, databases, whatever, don't.
...
The general scope of what you are thinking about seems to me so easily implemented inside LC, that it is a no-brainer.

Thanks, Craig. This makes a lot of sense. And, honestly, the more I think about how I'd like the application to work, the more sense it makes. For example, I want to be able to automatically defer incomplete action items to the following day. This seems like a headache with individual flat files.

On the other hand, I'm a little intimidated about card creation in a date-based application when I want to be able to jump to any date at any time. With individual flat files, I'd just check to see if the file exists and, if not, create it. I'm sure the same can be done with cards, but I just don't have my brain wrapped around it since I've been out of the development scene since the early 2000s. I'm not sure of the mechanisms to reorder cards and make sure they are chronological by date, and so on.

[bogs]

Maybe something like "set the name of (your new card) to the (long/short/abbr.) date" would work?

[hypercardjdowns]

Maybe something like "set the name of (your new card) to the (long/short/abbr.) date" would work?

Yes, I was thinking of converting to a numerals-only date that might simplify the ordering and any date-based calculations that may be needed.

[dunbarx]

Hi.

Unless you plan on having thousands of cards, which will slow LC down, I see nothing wrong. After all, you will not see any but the single relevant card at any one time. The advantage is that cards contain all their own information, can be edited directly and can be ordered and searched quickly and simply.

The only other way to do this and still stay "inside" LC, is to have a single "working" card and maintain all the data in a table somewhere, perhaps a table field or DG on another card. That so you can still edit information directly. Then you have the working card pull data from the data card when you execute a query; the user experience will be identical.

This should be a no brainer.

Craig

[bogs]

I was thinking of converting to a numerals-only date

That is certainly easy enough -

Code: Select all

put the short date into tmpDate 
set the itemDelimiter to slash
new card item 1 of tmpDate & item 2 of tmpDate & item 3 of tmpDate

Easy as 1, 2, 3...

You could probably also use replace instead, something like -

Code: Select all

put the short date into tmpDate 
replace slash with empty in tmpDate

new card tmpDate

[Klaus]

We should not name LC objects with numbers, so I really doubt this is a glorious idea.
Add a c at the beginning (-> c102719 or c_102719) or something like that to disarm the situation.

[bogs]

Your right Klaus, that last one would be

Code: Select all

put the short date into tmpDate 
replace slash with empty in tmpDate

new card "c_" & tmpDate

[Klaus]

Code: Select all

...
new card ("c_" & tmpDate)
...