How to extract certain parts of fieldname seperately

#1

In my budget wiki, I store shopping details in the fields like this

fieldname: double-chocolate-marble-cake_700-gm_1-nos 
fieldvalue: 400

I found that I can list the those field using this

{{{ [<currentTiddler>fields[]suffix[-nos]] }}}

I want to create a table (which will be displayed using a view-template cascade) where I want to list the name, quantity and price of the purchased items.

I can list the name of the purchased items like this

{{{ [<currentTiddler>fields[]suffix[-nos]splitbefore[_]removesuffix[_]] }}}

which will return double-chocolate-marble-cake as result.

But how to extract the rest of the parts of the fieldnames separately like 700-gm and 2-nos

#2

I’m quite surprised at this use of informationally-dense compound field names, and not sure whether it might cause complications. In effect, you’re putting field-value information into parts of fieldnames. :thinking: … and then needing to do complex filter-operations to retrieve those chunks of information.

At any rate, to answer your question, the split[] operator allows you to go on to retrieve the first value, the last value, and/or any number of middle values, using first, last, butfirst, butlast, etc.

{{{ [<currentTiddler>fields[]suffix[-nos]split[_]butfirst[]first[]] }}}

will isolate the second value, for example (700-gm, in this case)

{{{ [<currentTiddler>fields[]suffix[-nos]split[_]last[]] }}}

would get you the 2-nos part…

Still, I’d love to invite you to discuss why you’ve chosen such a convoluted way of using concatenated field-names to hold actual data…

For what it’s worth, my intuition is that the “line items” that you’re stuffing into the fields deserve to be tiddlers (which have some relational tie to whatever tiddler is currently housing them). Then the line items can have lots of internal structure which you can handle easily (without unpacking concatenated strings). And if you want to add a further dimension later, you won’t have to rework these filters to cope with the added complexity…

Especially because a recipes TiddlyWiki demo is already underway. I want to tag @Scott_Sauyet on this…

1 Like
#3

That was very quick reply and solution @Springer .Thank you. I haven’t used - last , butfirst and first operators yet. Thanks for the new learnings too.

This is for my budget wiki, not recipe wiki. For each debit and credit transactions, I create a transaction tiddler. So a visit to a grocery shop will be saved in a single tiddler- mainly using the tiddler fields and relevant data is displayed using viewtemplates. Text fields are almost empty in these tiddlers.
I plan to enter each item purchased from the shop in a single field. Using more fields will lead to overcrowding of the fields and it will be difficult to read.

So I thought of creating such compound field names - with a fixed uniform way of naming. Each fieldname will have item-name, item-weight and item-number combined together. Underscores are used to separate them. Hyphen is used instead of spaces in item name or quantity.

It’s little complex- so I have to do more testing to cover all scenarios. If there are no other issues, I will continue with this approach.

#4

I know, I know… but look over there, something shiny!

…Perhaps this weekend.

I agree with @Springer here. This feels more complicated than necessary. I could easily imagine

title: Trip 3/Item 7 (or arbitrary id)
tags: ShoppingListItem
trip: 3
item: Double-chocolate Marble Cake
size: 700 gm
count: 1
unit-price: 400

then a shopping list can look like

<$list filter="[tag[ShoppingListItem]trip<trip-number>sort[item]]"><<display-item>></$list>

where display-item formats your individual item as desired.

But perhaps even better would be

title: Double-chocolate Marble Cake
tags: Item
size: 700 gm
price: 400

title: s12345
tags: ListItem
trip: 3
item: Double-chocolate Marble Cake
quantity: 1

title: s98765
tags: ListItem
trip: 3
item: Broccoli Head
quantity: 2

Then the filter would be similar

<$list filter="[tag[ListItem]trip<trip-number>"><<display-item>></$list>

but display-item would need to be a bit more sophisticated.

1 Like
#5

I am not fully understanding this…Can you give me a small demo whenever you get time.

In my budget wiki, I have separate tiddlers for each day and for each expense. For example one tiddler for grocery shopping, one for car fuel fillings etc. In a single grocery shopping tiddler, there will be multiple items to be added to the fields. For each item there will be extra information like quantity, price and count.
That’s why I chose this method.

#6

The idea that I think both @Scott_Sauyet and I have is that these details should not be “IN” the grocery shopping (transaction) tiddler.

Each line item (detail within a transaction) should be a tiddler. You can do various things to make those tiddlers less visible if you like (put them in system namespace, starting with $:/ so they don’t clutter your sidebar, for example). You can even generate and access them from within the 2024-04-19-grocery-purchase transaction tiddler. But if you want these line items to have any “dimension” at all, you shouldn’t be trying to fit those details into a gerrymandered complex field title. Each line item ought to have its own tiddler, with fields for whatever you care about (quantity, price, size, brand, tickler-date-to-repurchase, whatever!).

By making a tiddler for each line item — even if you only interact with these tiddlers through a “portal” within the grocery trip tiddler — you enable yourself to handle their details with grace and flexibility. Fields are the right place for details that have a predictable role, and that you want to be able to compare, calculate with, and display (or hide) at a granular level.

One simple approach would be to have your “1 chocolate marble cake, 700gm” tiddler get a name that is just a system prefix followed by timestamp, because you won’t need to interact much with the tiddler itself. Description, quantity, size, and whatever else you care about go into fields.

When you generate the line-item tiddler (ideally with a button that automates the right setup), make sure it gets tagged with the shopping-trip transaction tiddler to which it belongs. (Or put that transaction connection in some other dedicated field, if you prefer to keep your tag array cleaner.)

WITHIN your shopping-transaction tiddler, you then include (ideally with a view template or cascade condition) a table that provides an overview of what was purchased (maybe a Shiraz dynamic table, if you like benefitting from wheels that other people have invented and refined well).

The table just pulls up whatever fields you care about, from all the line-item tiddlers within today’s batch. Want to add a new level of detail later (brand? flag-for-return? star-rating?)? Might you decide later to stop having to track some of those details? No worries, if they’re just fields!

Is that enough to get you started?

2 Likes
#7

I am understanding what you are saying and will test this approach. Only concern is that it shouldn’t be more time consuming. Also I am not sure whether I should create a new tiddler for every small purchase I make from a single shopping and there by increasing the tiddler count drastically in the long term.

I have been experimenting with budget related wikis for a long time - initially it was based on tiddlytables (here is an example - MW43)
But I shifted to my own html table based template last year. Currently this is a rough sample I am using. Tables are yet to be styled though.

#8

How about creating a parent tiddler for a purchase-type say for example marble-cake. For every subsequent cake purchases, add this data to a json tiddler called marble-cake/json-data. This json tiddler will be a little complex with at least one layer of nested data. But I don’t know how to create such complex json tiddler. I had tried to read about it in the past when I was planning to create this budget wiki, but I didn’t understand much about it.

Similar json tiddlers are used in this habit-tracker by sii which I modified with help of btheado

#9

My guess is that it will take more time to set up, but less day-to-day time to use. The first time you purchase an item, you would create it, specifying in different fields its various characteristics, ideally in an entry form. From then on it’s available from a list/search interface.

#10

Still I will have to create new tiddlers for those new purchased rite?
I will try this approach this week