Eric,
I thought I had missed this all a long, not that it was in the process of
creation. I have built a package for field definitions and they can be
assigned a field-type. The field type determines how a field will appear in
a number of modes such as view or edit and allows editing in the current
tiddler.
- Whilst many fields may just need transclude (to view) or edit-text
widget to edit, we often have fields that can be selected from a filter or
special values, such as the color field (that triggered this thread), or
existing values in a string or all matching fields in the wiki, or even all
tiddlers tagged with a special tag.
- It thus seems to me timely that you created edit-list for such cases,
rather than me coding each and every possibility (field-type edit macro) as
you seem to have done it.
- With the added bonus of all the special features such as type to
search.
Please consider my application here and consider if there would be a way to
simplify its use
- In this case when trying to edit a field I have the following key
variables already set *currentTiddler field.value fieldname
field-values-filter*
- So this appears to be the way I will use it
- <$macrocall $name=edit-list field=<<fieldname>>
filter=<<field-values-filter>> placeholder=<<field.placeholder>>
tooltip=<<field-tooltip>> id=???/>
- Now there variables will be supplemented with other parameters as
the need arises
So these two questions arise;
- Can we abolish the ID or make it equal to a *tiddler-title-fieldname*
(slugifyeld)?
- Yes I expect I will have multiple edit-list macros in one tiddler,
and possibly more than one tiddler displayed at once.
- Is there any way I could avoid passing the same parameter=value pairs
every time? such that I need only set the other parameters?
- field=<<fieldname>>
filter=<<field-values-filter>> placeholder=<<field.placeholder>>
tooltip=<<field-tooltip>>
- I could make a custom version of edit-list perhaps by modifying the
$vars widget?
Elsewhere I have used a design pattern where if the parameter is provided,
use it eg $parameter$, if the parameter is not provided eg emptyValue use
another source.
eg; field parameter has no value use <<fieldname>>
Is it correct then *if following the $vars widget in edit list* I could
specify something like this?
<$set name=field value=<<field>> emptyValue=<<fieldname>> >
<$set name= filter value=<<filter>> emptyValue=<<field-values-filter>> >
<$set name= placeholder value=<<placeholder>> emptyValue=
<<field.placeholder>> >
<$set name=tooltip value=<<tooltip>> emptyValue=<<field-tooltip>> >
Then before the closure of $vars place </$set></$set></$set></$set> *can
you tell me where this is?*
*Why ask now?*
My idea is if you *replace the $vars at the beginning* from the start with
something like this for every parameter;
<$set name=paramname value="""$paramname$""" emptyValue="">
Or something like
<$vars
field={{{ [[$field$]is[blank]then<fieldname>] }}}
paramname={{{ [[$paramname$]is[blank]then<varname>] }}}
>
Or any other variable!
Or perhaps just
field={{{ [[$field$]] }}} so it can be edited if desired to {{{
[[$field$]is[blank]then<fieldname>] }}}
It would become possible for pesky designer like me to edit the edit-list
macro to make use of my own variables, rather than parameters by providing
a variable in the matching set parameter, however if the $paramname$ is set
it will still behave as advertised/documented?
Then I could simply use <<edit-list>> OR <$macrocall $name=edit-list
*[additional
parameter values]* /> and my default variables will be used.
*I really appreciate your self documenting and well laid out macro*, it
makes it possible for me to modify, or more importantly ask you for this
feature, while presenting an actual mechaisium, hopefully to make such a
modification possible. If you can do this I may revisit my field
definitions and allow them to set the variables needed by the edit-list
macro if desired, making it much simpler to use, because I can guide the
user to providing the parameters needed to the edit-list macro.
Regards
Tones
On Monday, 26 July 2021 at 12:31:17 UTC+10 Eric Shulman wrote:
> On Sunday, July 25, 2021 at 3:57:13 AM UTC-7 TW Tones wrote:
>
>> That looks like a substantial piece of work your edit-list macro. I am
>> working on a fields handling package and this may be a good fit. Is it
>> production ready for its broader use?
>>
>
> I still working on improving it to the point where I can feel like it's
> "done" (if there is such a thing!) For example, in the past 2 days, I've
> simplified a lot of code to handle issues like automatically changing
> between default tiddlywiki type and application/json, so it can
> transparently handle a combination of fields and indexes in the same
> tiddler. I also reduced the complexity for handling focus and "activation"
> of input controls, so that fewer internal tracking tiddlers are required.
> And just this afternoon, I refactored the code to vastly reduce the need
> for manually specified unique IDs to differentiate popups.
>
> I've also built a "Tester" harness to try a variety of different parameter
> combinations and monitor the internal state tracking tiddlers for modal
> editing and popup list handling.
>
> I'm sure I'll find yet more deeply technical areas to improve, but all in
> all, I'd say it's ready for people to TRY IT OUT and so I can get some
> important feedback. Be sure to read the "Info" tiddler for specific
> details.
>
> Give it a whirl and let me know...
>
> https://tiddlytools.com/edit-list.html
> <https://tiddlytools.com/edit-list.html#TiddlyTools%2FMacros%2Fedit-list>
>
> Love your work
>>
>
> Aw shucks, thanks! :)
>
> enjoy,
> -e
>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/903b0ee8-65ee-4f26-80cf-2d7230b834e3n%40googlegroups.com.
