I just used my first CSS-bound screen yesterday and had a couple questions.
What is formName and where is it used?
Also, I had to include this:
override val allTemplate = defaultAllTemplate
What is an allTemplate, and is there a reason that defaultAllTemplate isn't the, uh, default allTemplate already? :) If I don't include that, wizard-all.html doesn't render.
Thanks, this looks interesting once I wrap my head around the new features.
I also used CSS-bound screen for the first time the day before yesterday. I
really like it.
Maybe a little documentation would be nice. I stumbled over a little
problem when trying to use it with twitter bootstrap because the labels
have class "label" by default which caused them to be rendered with the
bootstrap label class (which is not meant for forms). But this could be
solved by overriding cssClassBinding.
> I just used my first CSS-bound screen yesterday and had a couple questions.
> What is formName and where is it used?
> Also, I had to include this:
> override val allTemplate = defaultAllTemplate
> What is an allTemplate, and is there a reason that defaultAllTemplate
> isn't the, uh, default allTemplate already? :) If I don't include that,
> wizard-all.html doesn't render.
> Thanks, this looks interesting once I wrap my head around the new features.
Mind sharing the wizard-all.html that you used with Bootstrap?
I grabbed it from the demo project and snipped out the tables, intending to make a horizontal form. Nothing I did worked, though. I'm wondering if it is as simple as the labels having the label class? My markup looked fairly close to that of the examples, but I could never get the controls on the same line as the labels.
> I also used CSS-bound screen for the first time the day before > yesterday. I really like it.
> Maybe a little documentation would be nice. I stumbled over a little > problem when trying to use it with twitter bootstrap because the > labels have class "label" by default which caused them to be rendered > with the bootstrap label class (which is not meant for forms). But > this could be solved by overriding cssClassBinding.
> I just used my first CSS-bound screen yesterday and had a couple
> questions.
> What is formName and where is it used?
> Also, I had to include this:
> override val allTemplate = defaultAllTemplate
> What is an allTemplate, and is there a reason that
> defaultAllTemplate isn't the, uh, default allTemplate already? :)
> If I don't include that, wizard-all.html doesn't render.
> Thanks, this looks interesting once I wrap my head around the new
> features.
> Mind sharing the wizard-all.html that you used with Bootstrap?
> I grabbed it from the demo project and snipped out the tables, intending
> to make a horizontal form. Nothing I did worked, though. I'm wondering if
> it is as simple as the labels having the label class? My markup looked
> fairly close to that of the examples, but I could never get the controls on
> the same line as the labels.
> On 07/17/2012 11:11 AM, Stefan Bradl wrote:
> +1 for making defaultAllTemplate the default :)
> I also used CSS-bound screen for the first time the day before
> yesterday. I really like it.
> Maybe a little documentation would be nice. I stumbled over a little
> problem when trying to use it with twitter bootstrap because the labels
> have class "label" by default which caused them to be rendered with the
> bootstrap label class (which is not meant for forms). But this could be
> solved by overriding cssClassBinding.
>> I just used my first CSS-bound screen yesterday and had a couple
>> questions.
>> What is formName and where is it used?
>> Also, I had to include this:
>> override val allTemplate = defaultAllTemplate
>> What is an allTemplate, and is there a reason that defaultAllTemplate
>> isn't the, uh, default allTemplate already? :) If I don't include that,
>> wizard-all.html doesn't render.
>> Thanks, this looks interesting once I wrap my head around the new
>> features.
>> Mind sharing the wizard-all.html that you used with Bootstrap?
>> I grabbed it from the demo project and snipped out the tables, intending
>> to make a horizontal form. Nothing I did worked, though. I'm wondering if
>> it is as simple as the labels having the label class? My markup looked
>> fairly close to that of the examples, but I could never get the controls on
>> the same line as the labels.
>> On 07/17/2012 11:11 AM, Stefan Bradl wrote:
>> +1 for making defaultAllTemplate the default :)
>> I also used CSS-bound screen for the first time the day before
>> yesterday. I really like it.
>> Maybe a little documentation would be nice. I stumbled over a little
>> problem when trying to use it with twitter bootstrap because the labels
>> have class "label" by default which caused them to be rendered with the
>> bootstrap label class (which is not meant for forms). But this could be
>> solved by overriding cssClassBinding.
>>> I just used my first CSS-bound screen yesterday and had a couple
>>> questions.
>>> What is formName and where is it used?
>>> Also, I had to include this:
>>> override val allTemplate = defaultAllTemplate
>>> What is an allTemplate, and is there a reason that defaultAllTemplate
>>> isn't the, uh, default allTemplate already? :) If I don't include that,
>>> wizard-all.html doesn't render.
>>> Thanks, this looks interesting once I wrap my head around the new
>>> features.
The basic assumption was that if you're using CssBoundLiftScreen, you have
some custom layout requirements so it uses the snippet's children as the
template by default. It's certainly beneficial to have something that
works out of the box though so if this proves to be a common stumbling
block, I have no objection to changing it.
formName is used to create field IDs that are used as binding points when a
one-sized-fits-all field template doesn't work anymore. There are some
examples in the demo. It's also a handy way to manipulate the field using
client side JavaScript.
Also, if you turn on trace level logging for your screen, you'll get
voluminous logging about what's being bound where.
Regarding the field templates themselves, everything is based on CSS
classes. By default, labels are bound to class="label" / ".label" #> ...
(but as Stefan noted, this can be changed if necessary).
@Stefan --
I have been pondering a series of LiftScreen Lift Cookbook entries.
Overriding cssClassBinding seems a like a good candidate for one. This is
mentioned in the demo too.
Pete
On Tue, Jul 17, 2012 at 6:15 PM, Nolan Darilek <no...@thewordnerd.info>wrote:
> Mind sharing the wizard-all.html that you used with Bootstrap?
> I grabbed it from the demo project and snipped out the tables, intending
> to make a horizontal form. Nothing I did worked, though. I'm wondering if
> it is as simple as the labels having the label class? My markup looked
> fairly close to that of the examples, but I could never get the controls on
> the same line as the labels.
> On 07/17/2012 11:11 AM, Stefan Bradl wrote:
> +1 for making defaultAllTemplate the default :)
> I also used CSS-bound screen for the first time the day before
> yesterday. I really like it.
> Maybe a little documentation would be nice. I stumbled over a little
> problem when trying to use it with twitter bootstrap because the labels
> have class "label" by default which caused them to be rendered with the
> bootstrap label class (which is not meant for forms). But this could be
> solved by overriding cssClassBinding.
>> I just used my first CSS-bound screen yesterday and had a couple
>> questions.
>> What is formName and where is it used?
>> Also, I had to include this:
>> override val allTemplate = defaultAllTemplate
>> What is an allTemplate, and is there a reason that defaultAllTemplate
>> isn't the, uh, default allTemplate already? :) If I don't include that,
>> wizard-all.html doesn't render.
>> Thanks, this looks interesting once I wrap my head around the new
>> features.
On Tue, Jul 17, 2012 at 6:57 PM, Stefan Bradl <madreneg...@gmx.de> wrote:
> But I could not get the for validation to work. For this it would be
> necessary to add the error class to the control-group element :(
>>> Mind sharing the wizard-all.html that you used with Bootstrap?
>>> I grabbed it from the demo project and snipped out the tables, intending
>>> to make a horizontal form. Nothing I did worked, though. I'm wondering if
>>> it is as simple as the labels having the label class? My markup looked
>>> fairly close to that of the examples, but I could never get the controls on
>>> the same line as the labels.
>>> On 07/17/2012 11:11 AM, Stefan Bradl wrote:
>>> +1 for making defaultAllTemplate the default :)
>>> I also used CSS-bound screen for the first time the day before
>>> yesterday. I really like it.
>>> Maybe a little documentation would be nice. I stumbled over a little
>>> problem when trying to use it with twitter bootstrap because the labels
>>> have class "label" by default which caused them to be rendered with the
>>> bootstrap label class (which is not meant for forms). But this could be
>>> solved by overriding cssClassBinding.
>>>> I just used my first CSS-bound screen yesterday and had a couple
>>>> questions.
>>>> What is formName and where is it used?
>>>> Also, I had to include this:
>>>> override val allTemplate = defaultAllTemplate
>>>> What is an allTemplate, and is there a reason that defaultAllTemplate
>>>> isn't the, uh, default allTemplate already? :) If I don't include that,
>>>> wizard-all.html doesn't render.
>>>> Thanks, this looks interesting once I wrap my head around the new
>>>> features.
Here you can find how form validation in bootstrap works:
http://twitter.github.com/bootstrap/base-css.html#forms Basically you have a css-class "control-group". This is a container for the
label and the input field. For the bootstrap form validation to work the
css-class "error" needs to be added to the control group when a validation
error occurs. I found a function "additionalCssSelectors" or so, maybe this
can be used for this? Or maybe it is already working and I just couldn't
figure out how :P
>>>> Mind sharing the wizard-all.html that you used with Bootstrap?
>>>> I grabbed it from the demo project and snipped out the tables,
>>>> intending to make a horizontal form. Nothing I did worked, though. I'm
>>>> wondering if it is as simple as the labels having the label class? My
>>>> markup looked fairly close to that of the examples, but I could never get
>>>> the controls on the same line as the labels.
>>>> On 07/17/2012 11:11 AM, Stefan Bradl wrote:
>>>> +1 for making defaultAllTemplate the default :)
>>>> I also used CSS-bound screen for the first time the day before
>>>> yesterday. I really like it.
>>>> Maybe a little documentation would be nice. I stumbled over a little
>>>> problem when trying to use it with twitter bootstrap because the labels
>>>> have class "label" by default which caused them to be rendered with the
>>>> bootstrap label class (which is not meant for forms). But this could be
>>>> solved by overriding cssClassBinding.
>>>>> I just used my first CSS-bound screen yesterday and had a couple
>>>>> questions.
>>>>> What is formName and where is it used?
>>>>> Also, I had to include this:
>>>>> override val allTemplate = defaultAllTemplate
>>>>> What is an allTemplate, and is there a reason that defaultAllTemplate
>>>>> isn't the, uh, default allTemplate already? :) If I don't include that,
>>>>> wizard-all.html doesn't render.
>>>>> Thanks, this looks interesting once I wrap my head around the new
>>>>> features.
(in a nutshell, you can edit the rendered field using a CssSel by adding a
FieldTransform parameter to the field definition)
additionalFormBindings (whose name could be improved perhaps) is a CssSel
applied to the form as a whole (&'d together with the main transform).
It's handy for binding things that aren't field related (for example
attaching a local action to a button), but it can't modify field content
because it's not there yet.
On Tue, Jul 17, 2012 at 8:08 PM, Stefan Bradl <madreneg...@gmx.de> wrote:
> Elaborate the problem with form validation?
> Here you can find how form validation in bootstrap works:
> http://twitter.github.com/bootstrap/base-css.html#forms > Basically you have a css-class "control-group". This is a container for
> the label and the input field. For the bootstrap form validation to work
> the css-class "error" needs to be added to the control group when a
> validation error occurs. I found a function "additionalCssSelectors" or so,
> maybe this can be used for this? Or maybe it is already working and I just
> couldn't figure out how :P
>>>>> Mind sharing the wizard-all.html that you used with Bootstrap?
>>>>> I grabbed it from the demo project and snipped out the tables,
>>>>> intending to make a horizontal form. Nothing I did worked, though. I'm
>>>>> wondering if it is as simple as the labels having the label class? My
>>>>> markup looked fairly close to that of the examples, but I could never get
>>>>> the controls on the same line as the labels.
>>>>> On 07/17/2012 11:11 AM, Stefan Bradl wrote:
>>>>> +1 for making defaultAllTemplate the default :)
>>>>> I also used CSS-bound screen for the first time the day before
>>>>> yesterday. I really like it.
>>>>> Maybe a little documentation would be nice. I stumbled over a little
>>>>> problem when trying to use it with twitter bootstrap because the labels
>>>>> have class "label" by default which caused them to be rendered with the
>>>>> bootstrap label class (which is not meant for forms). But this could be
>>>>> solved by overriding cssClassBinding.
>>>>>> I just used my first CSS-bound screen yesterday and had a couple
>>>>>> questions.
>>>>>> What is formName and where is it used?
>>>>>> Also, I had to include this:
>>>>>> override val allTemplate = defaultAllTemplate
>>>>>> What is an allTemplate, and is there a reason that defaultAllTemplate
>>>>>> isn't the, uh, default allTemplate already? :) If I don't include that,
>>>>>> wizard-all.html doesn't render.
>>>>>> Thanks, this looks interesting once I wrap my head around the new
>>>>>> features.
I watched at the thread. I think using FieldTransform is not quite right
for me because I am using addFields. But I found another solution which
works fine for me:
I override validate in a base class for my screen like this:
override def validate = {
val errors = super.validate
for(error <- errors) {
error.field.uniqueFieldId match {
case Full(fieldName) => S.appendJs(JsCmds.Run("$('[for=\"" +
fieldName + "\"]').parent().addClass('error')"))
case _ =>
}
}
errors
}
But this is solution is specific to my template. So maybe it needs some
tweaking to be usable in a general case.
> (in a nutshell, you can edit the rendered field using a CssSel by adding a
> FieldTransform parameter to the field definition)
> additionalFormBindings (whose name could be improved perhaps) is a CssSel
> applied to the form as a whole (&'d together with the main transform).
> It's handy for binding things that aren't field related (for example
> attaching a local action to a button), but it can't modify field content
> because it's not there yet.
> Pete
> On Tue, Jul 17, 2012 at 8:08 PM, Stefan Bradl <madreneg...@gmx.de> wrote:
>> Elaborate the problem with form validation?
>> Here you can find how form validation in bootstrap works:
>> http://twitter.github.com/bootstrap/base-css.html#forms >> Basically you have a css-class "control-group". This is a container for
>> the label and the input field. For the bootstrap form validation to work
>> the css-class "error" needs to be added to the control group when a
>> validation error occurs. I found a function "additionalCssSelectors" or so,
>> maybe this can be used for this? Or maybe it is already working and I just
>> couldn't figure out how :P
>>>>>> Mind sharing the wizard-all.html that you used with Bootstrap?
>>>>>> I grabbed it from the demo project and snipped out the tables,
>>>>>> intending to make a horizontal form. Nothing I did worked, though. I'm
>>>>>> wondering if it is as simple as the labels having the label class? My
>>>>>> markup looked fairly close to that of the examples, but I could never get
>>>>>> the controls on the same line as the labels.
>>>>>> On 07/17/2012 11:11 AM, Stefan Bradl wrote:
>>>>>> +1 for making defaultAllTemplate the default :)
>>>>>> I also used CSS-bound screen for the first time the day before
>>>>>> yesterday. I really like it.
>>>>>> Maybe a little documentation would be nice. I stumbled over a little
>>>>>> problem when trying to use it with twitter bootstrap because the labels
>>>>>> have class "label" by default which caused them to be rendered with the
>>>>>> bootstrap label class (which is not meant for forms). But this could be
>>>>>> solved by overriding cssClassBinding.
>>>>>>> I just used my first CSS-bound screen yesterday and had a couple
>>>>>>> questions.
>>>>>>> What is formName and where is it used?
>>>>>>> Also, I had to include this:
>>>>>>> override val allTemplate = defaultAllTemplate
>>>>>>> What is an allTemplate, and is there a reason that
>>>>>>> defaultAllTemplate isn't the, uh, default allTemplate already? :) If I
>>>>>>> don't include that, wizard-all.html doesn't render.
>>>>>>> Thanks, this looks interesting once I wrap my head around the new
>>>>>>> features.
> The basic assumption was that if you're using CssBoundLiftScreen, you > have some custom layout requirements so it uses the snippet's children > as the template by default. It's certainly beneficial to have > something that works out of the box though so if this proves to be a > common stumbling block,
Actually, I was a bit surprised that the CSS binding wasn't rolled into default LiftScreen. Initially I dumped the template from the demo project into mine and attempted to use it unmodified, then ran into the allTemplate = defaultAllTemplate issue after discovering that I had to pick a different screen superclass.
Is the CSS-bound screen equivalent to LiftScreen in every other way if the newer style template is used? Given Lift's general trend toward CSS binding and away from namespaced attributes, I wonder if it might be worth making the CSS-bound screens as much of a drop-in replacement for LiftScreen as possible such that the default case just works, then deprecating LiftScreen a few major versions down the road? The old wizard-all.html is such an anachronism next to the newer, nicer templates, so it makes sense to gradually phase out the older implementation if the newer one can be made as compatible and easy as possible. I'm not using the newer CSS screens because I have strict template requirements. I'm using it because I want to use CSS binding across all my codebases, and wizard-all.html was the one place that couldn't be done (that I know of, anyway.)
Peter Brant <peter.br...@gmail.com> writes:
> @Nolan --
> The basic assumption was that if you're using CssBoundLiftScreen, you have
> some custom layout requirements so it uses the snippet's children as the
> template by default. It's certainly beneficial to have something that
> works out of the box though so if this proves to be a common stumbling
> block, I have no objection to changing it.
I think it makes good sense to provide some reasonable defaults
ootb. It always makes tinkering easier when you can adjust a few
parameters on something that already works.
The functionality provided by CssBoundLiftScreen is a proper superset of
LiftScreen's. If you just want to use it for CSS style one size fits all
templating, that works. If you have more involved requirements, it has a
number of features to support this.
Pete
On Wed, Jul 18, 2012 at 5:19 AM, Nolan Darilek <no...@thewordnerd.info>wrote:
>> The basic assumption was that if you're using CssBoundLiftScreen, you
>> have some custom layout requirements so it uses the snippet's children as
>> the template by default. It's certainly beneficial to have something that
>> works out of the box though so if this proves to be a common stumbling
>> block,
> Actually, I was a bit surprised that the CSS binding wasn't rolled into
> default LiftScreen. Initially I dumped the template from the demo project
> into mine and attempted to use it unmodified, then ran into the allTemplate
> = defaultAllTemplate issue after discovering that I had to pick a different
> screen superclass.
> Is the CSS-bound screen equivalent to LiftScreen in every other way if the
> newer style template is used? Given Lift's general trend toward CSS binding
> and away from namespaced attributes, I wonder if it might be worth making
> the CSS-bound screens as much of a drop-in replacement for LiftScreen as
> possible such that the default case just works, then deprecating LiftScreen
> a few major versions down the road? The old wizard-all.html is such an
> anachronism next to the newer, nicer templates, so it makes sense to
> gradually phase out the older implementation if the newer one can be made
> as compatible and easy as possible. I'm not using the newer CSS screens
> because I have strict template requirements. I'm using it because I want to
> use CSS binding across all my codebases, and wizard-all.html was the one
> place that couldn't be done (that I know of, anyway.)
