"field - Specifies a field to be placed in a form, corresponding to a
template field. The name immediately following the field declaration
is the name of the template field."
I think that text could be clearer, but it does suggest that you need
to use the above format rather than what you have (the clue was the
'uploadable' string turning up in the template).
In documentation I'd recommend the use of the term 'template
parameter' over 'template field' to mean the string used to identify a
variable in the template call. i.e.
{{ my template | some such = so and so }}
whole thing = template call.
"my template" = template name.
"some such" = template parameter.
"so and so" = value of the parameter.
HTH,
Dan.
P.S. How come 'forminput' doesn't have named parameters? Is it a limit
of the way parser functions work, or it just hasn't been coded that
way?
P.P.S. Martien, were you in irc://irc.freenode.net/#semanticmediawiki
the other day? I am in there now if you want to work on some problems
in real time instead of by esnail ;-)
> "field - Specifies a field to be placed in a form, corresponding to a
> template field. The name immediately following the field declaration
> is the name of the template field."
> I think that text could be clearer, but it does suggest that you need
> to use the above format rather than what you have (the clue was the
> 'uploadable' string turning up in the template).
> In documentation I'd recommend the use of the term 'template
> parameter' over 'template field' to mean the string used to identify a
> variable in the template call. i.e.
> {{ my template | some such = so and so }}
> whole thing = template call.
> "my template" = template name.
> "some such" = template parameter.
> "so and so" = value of the parameter.
> HTH,
> Dan.
> P.S. How come 'forminput' doesn't have named parameters? Is it a limit
> of the way parser functions work, or it just hasn't been coded that
> way?
> P.P.S. Martien, were you in irc://irc.freenode.net/#semanticmediawiki
> the other day? I am in there now if you want to work on some problems
> in real time instead of by esnail ;-)
> > "field - Specifies a field to be placed in a form, corresponding to a
> > template field. The name immediately following the field declaration
> > is the name of the template field."
> > I think that text could be clearer, but it does suggest that you need
> > to use the above format rather than what you have (the clue was the
> > 'uploadable' string turning up in the template).
> > In documentation I'd recommend the use of the term 'template
> > parameter' over 'template field' to mean the string used to identify a
> > variable in the template call. i.e.
> > {{ my template | some such = so and so }}
> > whole thing = template call.
> > "my template" = template name.
> > "some such" = template parameter.
> > "so and so" = value of the parameter.
> > HTH,
> > Dan.
> > P.S. How come 'forminput' doesn't have named parameters? Is it a limit
> > of the way parser functions work, or it just hasn't been coded that
> > way?
Thanks! ISH (It Sure Helps) This fixes it. Stupid I didn't see it.
Sometimes I develop tunnel vision… And yes, the documentation can be
improved in order to make this clearer. The documentation is complete
and accurate and just like a UNIX man(1) page: terse and precise. Must
read it at least three times to completely grasp what is says.
Kudos to Yarion for creating this wonderful semantic forms stuff,
though. With Yaron's consent, I'll be happy to make some minor
adjustments to the documentation. Yaron?
Martien.
On Jul 4, 2:32 pm, Dan Bolser <dan.bol...@gmail.com> wrote:
> "field - Specifies a field to be placed in a form, corresponding to a
> template field. The name immediately following the field declaration
> is the name of the template field."
> I think that text could be clearer, but it does suggest that you need
> to use the above format rather than what you have (the clue was the
> 'uploadable' string turning up in the template).
> In documentation I'd recommend the use of the term 'template
> parameter' over 'template field' to mean the string used to identify a
> variable in the template call. i.e.
> {{ my template | some such = so and so }}
> whole thing = template call.
> "my template" = template name.
> "some such" = template parameter.
> "so and so" = value of the parameter.
> HTH,
> Dan.
> P.S. How come 'forminput' doesn't have named parameters? Is it a limit
> of the way parser functions work, or it just hasn't been coded that
> way?
> "field - Specifies a field to be placed in a form, corresponding to a
> template field. The name immediately following the field declaration
> is the name of the template field."
> I think that text could be clearer, but it does suggest that you need
> to use the above format rather than what you have (the clue was the
> 'uploadable' string turning up in the template).
> In documentation I'd recommend the use of the term 'template
> parameter' over 'template field' to mean the string used to identify a
> variable in the template call. i.e.
> {{ my template | some such = so and so }}
> whole thing = template call.
> "my template" = template name.
> "some such" = template parameter.
> "so and so" = value of the parameter.
> HTH,
> Dan.
> P.S. How come 'forminput' doesn't have named parameters? Is it a limit
> of the way parser functions work, or it just hasn't been coded that
> way?
> Thanks! ISH (It Sure Helps) This fixes it. Stupid I didn't see it.
> Sometimes I develop tunnel vision… And yes, the documentation can be
> improved in order to make this clearer. The documentation is complete
> and accurate and just like a UNIX man(1) page: terse and precise. Must
> read it at least three times to completely grasp what is says.
> Kudos to Yarion for creating this wonderful semantic forms stuff,
> though. With Yaron's consent, I'll be happy to make some minor
> adjustments to the documentation. Yaron?
Its wiki! Anyone can edit! I'm sure Yaron will review any major
changes, so its probably safe to fire away... could we get *this*
email address on the SF / SD watchlist? That would be really cool.
I'm just getting round to some edits on SD myself :-)
Its too massive to go through the whole thing, but I think its good to
add corrections, clarifications and comments when they are fresh in
your mind.
I'd like to split the docs (especially for SF) into chapters to make
it easier to focus on specific features.
>> "field - Specifies a field to be placed in a form, corresponding to a
>> template field. The name immediately following the field declaration
>> is the name of the template field."
>> I think that text could be clearer, but it does suggest that you need
>> to use the above format rather than what you have (the clue was the
>> 'uploadable' string turning up in the template).
>> In documentation I'd recommend the use of the term 'template
>> parameter' over 'template field' to mean the string used to identify a
>> variable in the template call. i.e.
>> {{ my template | some such = so and so }}
>> whole thing = template call.
>> "my template" = template name.
>> "some such" = template parameter.
>> "so and so" = value of the parameter.
>> HTH,
>> Dan.
>> P.S. How come 'forminput' doesn't have named parameters? Is it a limit
>> of the way parser functions work, or it just hasn't been coded that
>> way?
Yes, anyone should feel free to make any changes they think will improve the
wiki documentation (though try to avoid major structural changes unless you
really think you know what you're doing). And - ouch. :) But I'm looking
forward to your improvements.
Dan - really, you want an email to be sent to the list every time a change
is made to the SF or SD documentation pages? I don't know if everyone on the
list would be happy about that...
Also, the #forminput question - it's totally unrelated, but: the lack of
parameter names isn't a technical issue, it was just my choice - I thought
five parameters was low enough to be handled without names.
> > Thanks! ISH (It Sure Helps) This fixes it. Stupid I didn't see it.
> > Sometimes I develop tunnel vision… And yes, the documentation can be
> > improved in order to make this clearer. The documentation is complete
> > and accurate and just like a UNIX man(1) page: terse and precise. Must
> > read it at least three times to completely grasp what is says.
> > Kudos to Yarion for creating this wonderful semantic forms stuff,
> > though. With Yaron's consent, I'll be happy to make some minor
> > adjustments to the documentation. Yaron?
> Its wiki! Anyone can edit! I'm sure Yaron will review any major
> changes, so its probably safe to fire away... could we get *this*
> email address on the SF / SD watchlist? That would be really cool.
> I'm just getting round to some edits on SD myself :-)
> Its too massive to go through the whole thing, but I think its good to
> add corrections, clarifications and comments when they are fresh in
> your mind.
> I'd like to split the docs (especially for SF) into chapters to make
> it easier to focus on specific features.
> GICH! (Glad I Could Help! ;-)
> Dan.
> > Martien.
> > On Jul 4, 2:32 pm, Dan Bolser <dan.bol...@gmail.com> wrote:
> >> 2009/7/4 Martien <martien.van.steenber...@gmail.com>:
> >> > Given: Form:Test, Template:Test, Category:Test according to basic
> >> > setup.
> >> "field - Specifies a field to be placed in a form, corresponding to a
> >> template field. The name immediately following the field declaration
> >> is the name of the template field."
> >> I think that text could be clearer, but it does suggest that you need
> >> to use the above format rather than what you have (the clue was the
> >> 'uploadable' string turning up in the template).
> >> In documentation I'd recommend the use of the term 'template
> >> parameter' over 'template field' to mean the string used to identify a
> >> variable in the template call. i.e.
> >> {{ my template | some such = so and so }}
> >> whole thing = template call.
> >> "my template" = template name.
> >> "some such" = template parameter.
> >> "so and so" = value of the parameter.
> >> HTH,
> >> Dan.
> >> P.S. How come 'forminput' doesn't have named parameters? Is it a limit
> >> of the way parser functions work, or it just hasn't been coded that
> >> way?
|
