You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2020/09/08 20:47:07 UTC

Thinking about Jewel Forms refactor

Hi all,

Jewel Form and FormItem specially, was implemented in a way that I never
was happy. Also others like Piotr had problems doing certain things.
So I was thinking of doing a big refactor, I think it will be important
before we reach 1.0. But before doing this I was thinking first of leaving
the actual Form and FormItem code available for some time as "deprecated"
to be able to take the name for the new components. Another option could be
to make the refactor over the actual control, but that will mean breaking
actual code, so I think that will be a bad idea. Doing this way, you just
need to rename both components in all your apps to the new name so that
seems pretty easy so far.

So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for "Deprecated").
That means that initially, Form and FormDPCT will have the same code, and
FormItem and FormItemDPCT will have the same code too. If you have other
proposals for the new name let me know.

The refactor will do a better Form and FormItem responsive, so I think it
is better to layout vertically (label then content controls) by default and
take all available width in mobile screens. I think we'll need two layouts
for the FormItem, one for layout label and content controls, and other for
the content controls itself. Default will be all vertical.

Then we'll be able to add other jewel layout beads to make all horizontal
or just some parts.
I think that way we'll have all flexibility.

@Piotr (and others). I think it is the time to put in this thread anything
you think I should consider in this refactor, so if you remember the main
issues please take the time to log in this thread so I can have in mind.

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Thinking about Jewel Forms refactor

Posted by Carlos Rovira <ca...@apache.org>.
Hi Right,

I know this is normal :). Just saying that is just what I want to avoid for
things already in place. At least my objective is to reach 1.0 with the
current set working as expected, or IOW, that will be enough consistent and
will not cause current users to change their code because APIs change or
current implementations are not as generalistic as possible and we see that
we'll need to change implementation some time in the future.


El mié., 9 sept. 2020 a las 10:04, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:

> Carlos,
>
> Having working that way is a loooooong journey. You cannot expect that
> Royale application which is in production and using beta version of
> framework - will wait with features to have improvement to component. -
> There is much more custom extensions which we have made to move forward,
> cause writing something from scratch was too much time consuming, instead
> just do some hack and move forward. ;)
>
> IF we will be in Vuetify quality - we can really talk about such
> expectations as you have, but we are not. Maybe some day...
>
> Thanks,
> Piotr
>
> śr., 9 wrz 2020 o 09:52 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
> > Ok, that's what I want to avoid, having unofficial extensions for
> > something that we should provide out of the box.
> > We need to provide the flexibility to do all that kind of layouts and
> then
> > users could extend from that to adapt to some particular less
> generalistic
> > use cases, but the components should be sufficient 99% of the time.
> >
> >
> > El mié., 9 sept. 2020 a las 9:46, Piotr Zarzycki (<
> > piotrzarzycki21@gmail.com>) escribió:
> >
> >> What's more Hugo is using my extension as well - cause he expressed need
> >> of that -  I have send him off the list that one. I'm not the only
> person
> >> who uses in their app stacked Form.
> >>
> >> śr., 9 wrz 2020 o 09:45 Piotr Zarzycki <pi...@gmail.com>
> >> napisał(a):
> >>
> >>> Yes I have more extension of current Form - I didn't commit this to
> >>> Royale in the results of our discussion a while ago. I have made
> >>> significant changes to FormView to improve it and created stacked form
> >>> layout.
> >>>
> >>> Anyway go ahead and do whatever you think - let me know and I will
> apply
> >>> your changes to our app using your branch.
> >>>
> >>> śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org>
> >>> napisał(a):
> >>>
> >>>> Hi Piotr,
> >>>>
> >>>> don't understand all you said. You mean you have a stacked form layout
> >>>> now? that maybe is because you created your own extensions?
> >>>>
> >>>> I think the objective here should be to work on a final implementation
> >>>> that makes the Form/FormItem components behave in the most general way
> >>>> while it's easy to do other kinds of layouts. I'm afraid of people
> having
> >>>> problems as they start using it because the actual Form set is very
> >>>> "particular". So it's not a problem for me to work on that to make it
> as
> >>>> more "general" as possible. As I end changes you can I'll try to give
> a way
> >>>> to make it work as before too, I hopefully think it could be possible.
> >>>> Other things could be if people have some personal extensions or
> changes,
> >>>> since that could make it more difficult for them to change to the new
> one,
> >>>> but I expect the new Form will have a better look and feel.
> >>>>
> >>>>
> >>>> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
> >>>> piotrzarzycki21@gmail.com>) escribió:
> >>>>
> >>>>> Carlos,
> >>>>>
> >>>>> If you won't do  stacked in the first shot - I won't use it - We have
> >>>>> a lot of stacked stuff in our app. Without it it will just fail and
> apart
> >>>>> of changing code I will have to change more.. Sure if I have time I
> will
> >>>>> help, but I cannot promise I will get time for this from company.
> >>>>>
> >>>>> Having stuff in branch prevents me from changing my app till
> >>>>> everything work fully. - I can test stuf separately - instead deal
> with
> >>>>> some changes earlier in app and hold myself from using newest
> nightly.
> >>>>> Branch is the way to go in my opinion.
> >>>>>
> >>>>> Thanks,
> >>>>> Piotr
> >>>>>
> >>>>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
> >>>>> napisał(a):
> >>>>>
> >>>>>> Hi Piotr,
> >>>>>>
> >>>>>> (sending this to both user and dev since it affects to current users
> >>>>>> and we're discussing how to work on it)
> >>>>>>
> >>>>>> I prefer your approach to work in a branch over the current Form
> >>>>>> code, when finished it will require as well do some changes in
> final user
> >>>>>> code so in the end changes should be done one way or the other.
> it's ok for
> >>>>>> me. I'll be waiting a bit for any other input about this, and if
> nobody
> >>>>>> opposite will go that route.
> >>>>>>
> >>>>>> I think the default will become "stacked" since I think is the most
> >>>>>> typical/used, then we can have other flavours like the current
> layout
> >>>>>> (horizontal) and even the one show in vuetify or material where
> labels
> >>>>>> start as prompt and then shrink to the top of the control (for
> textinput),
> >>>>>> but I guess this could be a bead at form level that. Probably for
> people
> >>>>>> happy with the current layout they could continue using it
> overriding the
> >>>>>> set of default beads in his app's css (hopefully).
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
> >>>>>> piotrzarzycki21@gmail.com>) escribió:
> >>>>>>
> >>>>>>> Hi Carlos,
> >>>>>>>
> >>>>>>> If you think about changing name of the current component to
> >>>>>>> FormDPCT and write new one with old name - I prefer if you do just
> the
> >>>>>>> opposite. Name your new component in some way - once you will be
> ready - we
> >>>>>>> will test it and decide how it's working.
> >>>>>>>
> >>>>>>> IMO it should be done on the branch - if that's the case you can
> >>>>>>> even do not have name/rename, but just go ahead and change current
> Form.
> >>>>>>>
> >>>>>>> I do definitely wanted to see FormItem working as it is now + have
> >>>>>>> stacked Form item where label is on top - you can search - there
> were such
> >>>>>>> component in flex.
> >>>>>>>
> >>>>>>> I think also that our Form shouldn't contains to many pieces -
> Right
> >>>>>>> now I have label on the left, container on the right - it's taking
> too much
> >>>>>>> space - even if it will be super responsive.
> >>>>>>> I do work daily with Vuetify and this is good and non heavy example
> >>>>>>> how Forms should work and eventually look like [1]
> >>>>>>>
> >>>>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Piotr
> >>>>>>>
> >>>>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
> >>>>>>> napisał(a):
> >>>>>>>
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>> Jewel Form and FormItem specially, was implemented in a way that I
> >>>>>>>> never was happy. Also others like Piotr had problems doing
> certain things.
> >>>>>>>> So I was thinking of doing a big refactor, I think it will be
> >>>>>>>> important before we reach 1.0. But before doing this I was
> thinking first
> >>>>>>>> of leaving the actual Form and FormItem code available for some
> time as
> >>>>>>>> "deprecated" to be able to take the name for the new components.
> Another
> >>>>>>>> option could be to make the refactor over the actual control, but
> that will
> >>>>>>>> mean breaking actual code, so I think that will be a bad idea.
> Doing this
> >>>>>>>> way, you just need to rename both components in all your apps to
> the new
> >>>>>>>> name so that seems pretty easy so far.
> >>>>>>>>
> >>>>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
> >>>>>>>> "Deprecated"). That means that initially, Form and FormDPCT will
> have the
> >>>>>>>> same code, and FormItem and FormItemDPCT will have the same code
> too. If
> >>>>>>>> you have other proposals for the new name let me know.
> >>>>>>>>
> >>>>>>>> The refactor will do a better Form and FormItem responsive, so I
> >>>>>>>> think it is better to layout vertically (label then content
> controls) by
> >>>>>>>> default and take all available width in mobile screens. I think
> we'll need
> >>>>>>>> two layouts for the FormItem, one for layout label and content
> controls,
> >>>>>>>> and other for the content controls itself. Default will be all
> vertical.
> >>>>>>>>
> >>>>>>>> Then we'll be able to add other jewel layout beads to make all
> >>>>>>>> horizontal or just some parts.
> >>>>>>>> I think that way we'll have all flexibility.
> >>>>>>>>
> >>>>>>>> @Piotr (and others). I think it is the time to put in this thread
> >>>>>>>> anything you think I should consider in this refactor, so if you
> remember
> >>>>>>>> the main issues please take the time to log in this thread so I
> can have in
> >>>>>>>> mind.
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Carlos Rovira
> >>>>>>>> http://about.me/carlosrovira
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Piotr Zarzycki
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Carlos Rovira
> >>>>>> http://about.me/carlosrovira
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Piotr Zarzycki
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>> http://about.me/carlosrovira
> >>>>
> >>>>
> >>>
> >>> --
> >>>
> >>> Piotr Zarzycki
> >>>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
> >
>
> --
>
> Piotr Zarzycki
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Thinking about Jewel Forms refactor

Posted by Carlos Rovira <ca...@apache.org>.
Hi Right,

I know this is normal :). Just saying that is just what I want to avoid for
things already in place. At least my objective is to reach 1.0 with the
current set working as expected, or IOW, that will be enough consistent and
will not cause current users to change their code because APIs change or
current implementations are not as generalistic as possible and we see that
we'll need to change implementation some time in the future.


El mié., 9 sept. 2020 a las 10:04, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:

> Carlos,
>
> Having working that way is a loooooong journey. You cannot expect that
> Royale application which is in production and using beta version of
> framework - will wait with features to have improvement to component. -
> There is much more custom extensions which we have made to move forward,
> cause writing something from scratch was too much time consuming, instead
> just do some hack and move forward. ;)
>
> IF we will be in Vuetify quality - we can really talk about such
> expectations as you have, but we are not. Maybe some day...
>
> Thanks,
> Piotr
>
> śr., 9 wrz 2020 o 09:52 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
> > Ok, that's what I want to avoid, having unofficial extensions for
> > something that we should provide out of the box.
> > We need to provide the flexibility to do all that kind of layouts and
> then
> > users could extend from that to adapt to some particular less
> generalistic
> > use cases, but the components should be sufficient 99% of the time.
> >
> >
> > El mié., 9 sept. 2020 a las 9:46, Piotr Zarzycki (<
> > piotrzarzycki21@gmail.com>) escribió:
> >
> >> What's more Hugo is using my extension as well - cause he expressed need
> >> of that -  I have send him off the list that one. I'm not the only
> person
> >> who uses in their app stacked Form.
> >>
> >> śr., 9 wrz 2020 o 09:45 Piotr Zarzycki <pi...@gmail.com>
> >> napisał(a):
> >>
> >>> Yes I have more extension of current Form - I didn't commit this to
> >>> Royale in the results of our discussion a while ago. I have made
> >>> significant changes to FormView to improve it and created stacked form
> >>> layout.
> >>>
> >>> Anyway go ahead and do whatever you think - let me know and I will
> apply
> >>> your changes to our app using your branch.
> >>>
> >>> śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org>
> >>> napisał(a):
> >>>
> >>>> Hi Piotr,
> >>>>
> >>>> don't understand all you said. You mean you have a stacked form layout
> >>>> now? that maybe is because you created your own extensions?
> >>>>
> >>>> I think the objective here should be to work on a final implementation
> >>>> that makes the Form/FormItem components behave in the most general way
> >>>> while it's easy to do other kinds of layouts. I'm afraid of people
> having
> >>>> problems as they start using it because the actual Form set is very
> >>>> "particular". So it's not a problem for me to work on that to make it
> as
> >>>> more "general" as possible. As I end changes you can I'll try to give
> a way
> >>>> to make it work as before too, I hopefully think it could be possible.
> >>>> Other things could be if people have some personal extensions or
> changes,
> >>>> since that could make it more difficult for them to change to the new
> one,
> >>>> but I expect the new Form will have a better look and feel.
> >>>>
> >>>>
> >>>> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
> >>>> piotrzarzycki21@gmail.com>) escribió:
> >>>>
> >>>>> Carlos,
> >>>>>
> >>>>> If you won't do  stacked in the first shot - I won't use it - We have
> >>>>> a lot of stacked stuff in our app. Without it it will just fail and
> apart
> >>>>> of changing code I will have to change more.. Sure if I have time I
> will
> >>>>> help, but I cannot promise I will get time for this from company.
> >>>>>
> >>>>> Having stuff in branch prevents me from changing my app till
> >>>>> everything work fully. - I can test stuf separately - instead deal
> with
> >>>>> some changes earlier in app and hold myself from using newest
> nightly.
> >>>>> Branch is the way to go in my opinion.
> >>>>>
> >>>>> Thanks,
> >>>>> Piotr
> >>>>>
> >>>>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
> >>>>> napisał(a):
> >>>>>
> >>>>>> Hi Piotr,
> >>>>>>
> >>>>>> (sending this to both user and dev since it affects to current users
> >>>>>> and we're discussing how to work on it)
> >>>>>>
> >>>>>> I prefer your approach to work in a branch over the current Form
> >>>>>> code, when finished it will require as well do some changes in
> final user
> >>>>>> code so in the end changes should be done one way or the other.
> it's ok for
> >>>>>> me. I'll be waiting a bit for any other input about this, and if
> nobody
> >>>>>> opposite will go that route.
> >>>>>>
> >>>>>> I think the default will become "stacked" since I think is the most
> >>>>>> typical/used, then we can have other flavours like the current
> layout
> >>>>>> (horizontal) and even the one show in vuetify or material where
> labels
> >>>>>> start as prompt and then shrink to the top of the control (for
> textinput),
> >>>>>> but I guess this could be a bead at form level that. Probably for
> people
> >>>>>> happy with the current layout they could continue using it
> overriding the
> >>>>>> set of default beads in his app's css (hopefully).
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
> >>>>>> piotrzarzycki21@gmail.com>) escribió:
> >>>>>>
> >>>>>>> Hi Carlos,
> >>>>>>>
> >>>>>>> If you think about changing name of the current component to
> >>>>>>> FormDPCT and write new one with old name - I prefer if you do just
> the
> >>>>>>> opposite. Name your new component in some way - once you will be
> ready - we
> >>>>>>> will test it and decide how it's working.
> >>>>>>>
> >>>>>>> IMO it should be done on the branch - if that's the case you can
> >>>>>>> even do not have name/rename, but just go ahead and change current
> Form.
> >>>>>>>
> >>>>>>> I do definitely wanted to see FormItem working as it is now + have
> >>>>>>> stacked Form item where label is on top - you can search - there
> were such
> >>>>>>> component in flex.
> >>>>>>>
> >>>>>>> I think also that our Form shouldn't contains to many pieces -
> Right
> >>>>>>> now I have label on the left, container on the right - it's taking
> too much
> >>>>>>> space - even if it will be super responsive.
> >>>>>>> I do work daily with Vuetify and this is good and non heavy example
> >>>>>>> how Forms should work and eventually look like [1]
> >>>>>>>
> >>>>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Piotr
> >>>>>>>
> >>>>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
> >>>>>>> napisał(a):
> >>>>>>>
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>> Jewel Form and FormItem specially, was implemented in a way that I
> >>>>>>>> never was happy. Also others like Piotr had problems doing
> certain things.
> >>>>>>>> So I was thinking of doing a big refactor, I think it will be
> >>>>>>>> important before we reach 1.0. But before doing this I was
> thinking first
> >>>>>>>> of leaving the actual Form and FormItem code available for some
> time as
> >>>>>>>> "deprecated" to be able to take the name for the new components.
> Another
> >>>>>>>> option could be to make the refactor over the actual control, but
> that will
> >>>>>>>> mean breaking actual code, so I think that will be a bad idea.
> Doing this
> >>>>>>>> way, you just need to rename both components in all your apps to
> the new
> >>>>>>>> name so that seems pretty easy so far.
> >>>>>>>>
> >>>>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
> >>>>>>>> "Deprecated"). That means that initially, Form and FormDPCT will
> have the
> >>>>>>>> same code, and FormItem and FormItemDPCT will have the same code
> too. If
> >>>>>>>> you have other proposals for the new name let me know.
> >>>>>>>>
> >>>>>>>> The refactor will do a better Form and FormItem responsive, so I
> >>>>>>>> think it is better to layout vertically (label then content
> controls) by
> >>>>>>>> default and take all available width in mobile screens. I think
> we'll need
> >>>>>>>> two layouts for the FormItem, one for layout label and content
> controls,
> >>>>>>>> and other for the content controls itself. Default will be all
> vertical.
> >>>>>>>>
> >>>>>>>> Then we'll be able to add other jewel layout beads to make all
> >>>>>>>> horizontal or just some parts.
> >>>>>>>> I think that way we'll have all flexibility.
> >>>>>>>>
> >>>>>>>> @Piotr (and others). I think it is the time to put in this thread
> >>>>>>>> anything you think I should consider in this refactor, so if you
> remember
> >>>>>>>> the main issues please take the time to log in this thread so I
> can have in
> >>>>>>>> mind.
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Carlos Rovira
> >>>>>>>> http://about.me/carlosrovira
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Piotr Zarzycki
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Carlos Rovira
> >>>>>> http://about.me/carlosrovira
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Piotr Zarzycki
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>> http://about.me/carlosrovira
> >>>>
> >>>>
> >>>
> >>> --
> >>>
> >>> Piotr Zarzycki
> >>>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
> >
>
> --
>
> Piotr Zarzycki
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Thinking about Jewel Forms refactor

Posted by Piotr Zarzycki <pi...@gmail.com>.
Carlos,

Having working that way is a loooooong journey. You cannot expect that
Royale application which is in production and using beta version of
framework - will wait with features to have improvement to component. -
There is much more custom extensions which we have made to move forward,
cause writing something from scratch was too much time consuming, instead
just do some hack and move forward. ;)

IF we will be in Vuetify quality - we can really talk about such
expectations as you have, but we are not. Maybe some day...

Thanks,
Piotr

śr., 9 wrz 2020 o 09:52 Carlos Rovira <ca...@apache.org> napisał(a):

> Ok, that's what I want to avoid, having unofficial extensions for
> something that we should provide out of the box.
> We need to provide the flexibility to do all that kind of layouts and then
> users could extend from that to adapt to some particular less generalistic
> use cases, but the components should be sufficient 99% of the time.
>
>
> El mié., 9 sept. 2020 a las 9:46, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
>> What's more Hugo is using my extension as well - cause he expressed need
>> of that -  I have send him off the list that one. I'm not the only person
>> who uses in their app stacked Form.
>>
>> śr., 9 wrz 2020 o 09:45 Piotr Zarzycki <pi...@gmail.com>
>> napisał(a):
>>
>>> Yes I have more extension of current Form - I didn't commit this to
>>> Royale in the results of our discussion a while ago. I have made
>>> significant changes to FormView to improve it and created stacked form
>>> layout.
>>>
>>> Anyway go ahead and do whatever you think - let me know and I will apply
>>> your changes to our app using your branch.
>>>
>>> śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org>
>>> napisał(a):
>>>
>>>> Hi Piotr,
>>>>
>>>> don't understand all you said. You mean you have a stacked form layout
>>>> now? that maybe is because you created your own extensions?
>>>>
>>>> I think the objective here should be to work on a final implementation
>>>> that makes the Form/FormItem components behave in the most general way
>>>> while it's easy to do other kinds of layouts. I'm afraid of people having
>>>> problems as they start using it because the actual Form set is very
>>>> "particular". So it's not a problem for me to work on that to make it as
>>>> more "general" as possible. As I end changes you can I'll try to give a way
>>>> to make it work as before too, I hopefully think it could be possible.
>>>> Other things could be if people have some personal extensions or changes,
>>>> since that could make it more difficult for them to change to the new one,
>>>> but I expect the new Form will have a better look and feel.
>>>>
>>>>
>>>> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
>>>> piotrzarzycki21@gmail.com>) escribió:
>>>>
>>>>> Carlos,
>>>>>
>>>>> If you won't do  stacked in the first shot - I won't use it - We have
>>>>> a lot of stacked stuff in our app. Without it it will just fail and apart
>>>>> of changing code I will have to change more.. Sure if I have time I will
>>>>> help, but I cannot promise I will get time for this from company.
>>>>>
>>>>> Having stuff in branch prevents me from changing my app till
>>>>> everything work fully. - I can test stuf separately - instead deal with
>>>>> some changes earlier in app and hold myself from using newest nightly.
>>>>> Branch is the way to go in my opinion.
>>>>>
>>>>> Thanks,
>>>>> Piotr
>>>>>
>>>>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
>>>>> napisał(a):
>>>>>
>>>>>> Hi Piotr,
>>>>>>
>>>>>> (sending this to both user and dev since it affects to current users
>>>>>> and we're discussing how to work on it)
>>>>>>
>>>>>> I prefer your approach to work in a branch over the current Form
>>>>>> code, when finished it will require as well do some changes in final user
>>>>>> code so in the end changes should be done one way or the other. it's ok for
>>>>>> me. I'll be waiting a bit for any other input about this, and if nobody
>>>>>> opposite will go that route.
>>>>>>
>>>>>> I think the default will become "stacked" since I think is the most
>>>>>> typical/used, then we can have other flavours like the current layout
>>>>>> (horizontal) and even the one show in vuetify or material where labels
>>>>>> start as prompt and then shrink to the top of the control (for textinput),
>>>>>> but I guess this could be a bead at form level that. Probably for people
>>>>>> happy with the current layout they could continue using it overriding the
>>>>>> set of default beads in his app's css (hopefully).
>>>>>>
>>>>>>
>>>>>>
>>>>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
>>>>>> piotrzarzycki21@gmail.com>) escribió:
>>>>>>
>>>>>>> Hi Carlos,
>>>>>>>
>>>>>>> If you think about changing name of the current component to
>>>>>>> FormDPCT and write new one with old name - I prefer if you do just the
>>>>>>> opposite. Name your new component in some way - once you will be ready - we
>>>>>>> will test it and decide how it's working.
>>>>>>>
>>>>>>> IMO it should be done on the branch - if that's the case you can
>>>>>>> even do not have name/rename, but just go ahead and change current Form.
>>>>>>>
>>>>>>> I do definitely wanted to see FormItem working as it is now + have
>>>>>>> stacked Form item where label is on top - you can search - there were such
>>>>>>> component in flex.
>>>>>>>
>>>>>>> I think also that our Form shouldn't contains to many pieces - Right
>>>>>>> now I have label on the left, container on the right - it's taking too much
>>>>>>> space - even if it will be super responsive.
>>>>>>> I do work daily with Vuetify and this is good and non heavy example
>>>>>>> how Forms should work and eventually look like [1]
>>>>>>>
>>>>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Piotr
>>>>>>>
>>>>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>>>>>>> napisał(a):
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Jewel Form and FormItem specially, was implemented in a way that I
>>>>>>>> never was happy. Also others like Piotr had problems doing certain things.
>>>>>>>> So I was thinking of doing a big refactor, I think it will be
>>>>>>>> important before we reach 1.0. But before doing this I was thinking first
>>>>>>>> of leaving the actual Form and FormItem code available for some time as
>>>>>>>> "deprecated" to be able to take the name for the new components. Another
>>>>>>>> option could be to make the refactor over the actual control, but that will
>>>>>>>> mean breaking actual code, so I think that will be a bad idea. Doing this
>>>>>>>> way, you just need to rename both components in all your apps to the new
>>>>>>>> name so that seems pretty easy so far.
>>>>>>>>
>>>>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>>>>>>>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>>>>>>>> same code, and FormItem and FormItemDPCT will have the same code too. If
>>>>>>>> you have other proposals for the new name let me know.
>>>>>>>>
>>>>>>>> The refactor will do a better Form and FormItem responsive, so I
>>>>>>>> think it is better to layout vertically (label then content controls) by
>>>>>>>> default and take all available width in mobile screens. I think we'll need
>>>>>>>> two layouts for the FormItem, one for layout label and content controls,
>>>>>>>> and other for the content controls itself. Default will be all vertical.
>>>>>>>>
>>>>>>>> Then we'll be able to add other jewel layout beads to make all
>>>>>>>> horizontal or just some parts.
>>>>>>>> I think that way we'll have all flexibility.
>>>>>>>>
>>>>>>>> @Piotr (and others). I think it is the time to put in this thread
>>>>>>>> anything you think I should consider in this refactor, so if you remember
>>>>>>>> the main issues please take the time to log in this thread so I can have in
>>>>>>>> mind.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Carlos Rovira
>>>>>>>> http://about.me/carlosrovira
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Piotr Zarzycki
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>> http://about.me/carlosrovira
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Piotr Zarzycki
>>>>>
>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> http://about.me/carlosrovira
>>>>
>>>>
>>>
>>> --
>>>
>>> Piotr Zarzycki
>>>
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>

-- 

Piotr Zarzycki

Re: Thinking about Jewel Forms refactor

Posted by Piotr Zarzycki <pi...@gmail.com>.
Carlos,

Having working that way is a loooooong journey. You cannot expect that
Royale application which is in production and using beta version of
framework - will wait with features to have improvement to component. -
There is much more custom extensions which we have made to move forward,
cause writing something from scratch was too much time consuming, instead
just do some hack and move forward. ;)

IF we will be in Vuetify quality - we can really talk about such
expectations as you have, but we are not. Maybe some day...

Thanks,
Piotr

śr., 9 wrz 2020 o 09:52 Carlos Rovira <ca...@apache.org> napisał(a):

> Ok, that's what I want to avoid, having unofficial extensions for
> something that we should provide out of the box.
> We need to provide the flexibility to do all that kind of layouts and then
> users could extend from that to adapt to some particular less generalistic
> use cases, but the components should be sufficient 99% of the time.
>
>
> El mié., 9 sept. 2020 a las 9:46, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
>> What's more Hugo is using my extension as well - cause he expressed need
>> of that -  I have send him off the list that one. I'm not the only person
>> who uses in their app stacked Form.
>>
>> śr., 9 wrz 2020 o 09:45 Piotr Zarzycki <pi...@gmail.com>
>> napisał(a):
>>
>>> Yes I have more extension of current Form - I didn't commit this to
>>> Royale in the results of our discussion a while ago. I have made
>>> significant changes to FormView to improve it and created stacked form
>>> layout.
>>>
>>> Anyway go ahead and do whatever you think - let me know and I will apply
>>> your changes to our app using your branch.
>>>
>>> śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org>
>>> napisał(a):
>>>
>>>> Hi Piotr,
>>>>
>>>> don't understand all you said. You mean you have a stacked form layout
>>>> now? that maybe is because you created your own extensions?
>>>>
>>>> I think the objective here should be to work on a final implementation
>>>> that makes the Form/FormItem components behave in the most general way
>>>> while it's easy to do other kinds of layouts. I'm afraid of people having
>>>> problems as they start using it because the actual Form set is very
>>>> "particular". So it's not a problem for me to work on that to make it as
>>>> more "general" as possible. As I end changes you can I'll try to give a way
>>>> to make it work as before too, I hopefully think it could be possible.
>>>> Other things could be if people have some personal extensions or changes,
>>>> since that could make it more difficult for them to change to the new one,
>>>> but I expect the new Form will have a better look and feel.
>>>>
>>>>
>>>> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
>>>> piotrzarzycki21@gmail.com>) escribió:
>>>>
>>>>> Carlos,
>>>>>
>>>>> If you won't do  stacked in the first shot - I won't use it - We have
>>>>> a lot of stacked stuff in our app. Without it it will just fail and apart
>>>>> of changing code I will have to change more.. Sure if I have time I will
>>>>> help, but I cannot promise I will get time for this from company.
>>>>>
>>>>> Having stuff in branch prevents me from changing my app till
>>>>> everything work fully. - I can test stuf separately - instead deal with
>>>>> some changes earlier in app and hold myself from using newest nightly.
>>>>> Branch is the way to go in my opinion.
>>>>>
>>>>> Thanks,
>>>>> Piotr
>>>>>
>>>>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
>>>>> napisał(a):
>>>>>
>>>>>> Hi Piotr,
>>>>>>
>>>>>> (sending this to both user and dev since it affects to current users
>>>>>> and we're discussing how to work on it)
>>>>>>
>>>>>> I prefer your approach to work in a branch over the current Form
>>>>>> code, when finished it will require as well do some changes in final user
>>>>>> code so in the end changes should be done one way or the other. it's ok for
>>>>>> me. I'll be waiting a bit for any other input about this, and if nobody
>>>>>> opposite will go that route.
>>>>>>
>>>>>> I think the default will become "stacked" since I think is the most
>>>>>> typical/used, then we can have other flavours like the current layout
>>>>>> (horizontal) and even the one show in vuetify or material where labels
>>>>>> start as prompt and then shrink to the top of the control (for textinput),
>>>>>> but I guess this could be a bead at form level that. Probably for people
>>>>>> happy with the current layout they could continue using it overriding the
>>>>>> set of default beads in his app's css (hopefully).
>>>>>>
>>>>>>
>>>>>>
>>>>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
>>>>>> piotrzarzycki21@gmail.com>) escribió:
>>>>>>
>>>>>>> Hi Carlos,
>>>>>>>
>>>>>>> If you think about changing name of the current component to
>>>>>>> FormDPCT and write new one with old name - I prefer if you do just the
>>>>>>> opposite. Name your new component in some way - once you will be ready - we
>>>>>>> will test it and decide how it's working.
>>>>>>>
>>>>>>> IMO it should be done on the branch - if that's the case you can
>>>>>>> even do not have name/rename, but just go ahead and change current Form.
>>>>>>>
>>>>>>> I do definitely wanted to see FormItem working as it is now + have
>>>>>>> stacked Form item where label is on top - you can search - there were such
>>>>>>> component in flex.
>>>>>>>
>>>>>>> I think also that our Form shouldn't contains to many pieces - Right
>>>>>>> now I have label on the left, container on the right - it's taking too much
>>>>>>> space - even if it will be super responsive.
>>>>>>> I do work daily with Vuetify and this is good and non heavy example
>>>>>>> how Forms should work and eventually look like [1]
>>>>>>>
>>>>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Piotr
>>>>>>>
>>>>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>>>>>>> napisał(a):
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Jewel Form and FormItem specially, was implemented in a way that I
>>>>>>>> never was happy. Also others like Piotr had problems doing certain things.
>>>>>>>> So I was thinking of doing a big refactor, I think it will be
>>>>>>>> important before we reach 1.0. But before doing this I was thinking first
>>>>>>>> of leaving the actual Form and FormItem code available for some time as
>>>>>>>> "deprecated" to be able to take the name for the new components. Another
>>>>>>>> option could be to make the refactor over the actual control, but that will
>>>>>>>> mean breaking actual code, so I think that will be a bad idea. Doing this
>>>>>>>> way, you just need to rename both components in all your apps to the new
>>>>>>>> name so that seems pretty easy so far.
>>>>>>>>
>>>>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>>>>>>>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>>>>>>>> same code, and FormItem and FormItemDPCT will have the same code too. If
>>>>>>>> you have other proposals for the new name let me know.
>>>>>>>>
>>>>>>>> The refactor will do a better Form and FormItem responsive, so I
>>>>>>>> think it is better to layout vertically (label then content controls) by
>>>>>>>> default and take all available width in mobile screens. I think we'll need
>>>>>>>> two layouts for the FormItem, one for layout label and content controls,
>>>>>>>> and other for the content controls itself. Default will be all vertical.
>>>>>>>>
>>>>>>>> Then we'll be able to add other jewel layout beads to make all
>>>>>>>> horizontal or just some parts.
>>>>>>>> I think that way we'll have all flexibility.
>>>>>>>>
>>>>>>>> @Piotr (and others). I think it is the time to put in this thread
>>>>>>>> anything you think I should consider in this refactor, so if you remember
>>>>>>>> the main issues please take the time to log in this thread so I can have in
>>>>>>>> mind.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Carlos Rovira
>>>>>>>> http://about.me/carlosrovira
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Piotr Zarzycki
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>> http://about.me/carlosrovira
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Piotr Zarzycki
>>>>>
>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> http://about.me/carlosrovira
>>>>
>>>>
>>>
>>> --
>>>
>>> Piotr Zarzycki
>>>
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>

-- 

Piotr Zarzycki

Re: Thinking about Jewel Forms refactor

Posted by Carlos Rovira <ca...@apache.org>.
Ok, that's what I want to avoid, having unofficial extensions for something
that we should provide out of the box.
We need to provide the flexibility to do all that kind of layouts and then
users could extend from that to adapt to some particular less generalistic
use cases, but the components should be sufficient 99% of the time.


El mié., 9 sept. 2020 a las 9:46, Piotr Zarzycki (<pi...@gmail.com>)
escribió:

> What's more Hugo is using my extension as well - cause he expressed need
> of that -  I have send him off the list that one. I'm not the only person
> who uses in their app stacked Form.
>
> śr., 9 wrz 2020 o 09:45 Piotr Zarzycki <pi...@gmail.com>
> napisał(a):
>
>> Yes I have more extension of current Form - I didn't commit this to
>> Royale in the results of our discussion a while ago. I have made
>> significant changes to FormView to improve it and created stacked form
>> layout.
>>
>> Anyway go ahead and do whatever you think - let me know and I will apply
>> your changes to our app using your branch.
>>
>> śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org>
>> napisał(a):
>>
>>> Hi Piotr,
>>>
>>> don't understand all you said. You mean you have a stacked form layout
>>> now? that maybe is because you created your own extensions?
>>>
>>> I think the objective here should be to work on a final implementation
>>> that makes the Form/FormItem components behave in the most general way
>>> while it's easy to do other kinds of layouts. I'm afraid of people having
>>> problems as they start using it because the actual Form set is very
>>> "particular". So it's not a problem for me to work on that to make it as
>>> more "general" as possible. As I end changes you can I'll try to give a way
>>> to make it work as before too, I hopefully think it could be possible.
>>> Other things could be if people have some personal extensions or changes,
>>> since that could make it more difficult for them to change to the new one,
>>> but I expect the new Form will have a better look and feel.
>>>
>>>
>>> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
>>> piotrzarzycki21@gmail.com>) escribió:
>>>
>>>> Carlos,
>>>>
>>>> If you won't do  stacked in the first shot - I won't use it - We have a
>>>> lot of stacked stuff in our app. Without it it will just fail and apart of
>>>> changing code I will have to change more.. Sure if I have time I will help,
>>>> but I cannot promise I will get time for this from company.
>>>>
>>>> Having stuff in branch prevents me from changing my app till
>>>> everything work fully. - I can test stuf separately - instead deal with
>>>> some changes earlier in app and hold myself from using newest nightly.
>>>> Branch is the way to go in my opinion.
>>>>
>>>> Thanks,
>>>> Piotr
>>>>
>>>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
>>>> napisał(a):
>>>>
>>>>> Hi Piotr,
>>>>>
>>>>> (sending this to both user and dev since it affects to current users
>>>>> and we're discussing how to work on it)
>>>>>
>>>>> I prefer your approach to work in a branch over the current Form code,
>>>>> when finished it will require as well do some changes in final user code so
>>>>> in the end changes should be done one way or the other. it's ok for me.
>>>>> I'll be waiting a bit for any other input about this, and if nobody
>>>>> opposite will go that route.
>>>>>
>>>>> I think the default will become "stacked" since I think is the most
>>>>> typical/used, then we can have other flavours like the current layout
>>>>> (horizontal) and even the one show in vuetify or material where labels
>>>>> start as prompt and then shrink to the top of the control (for textinput),
>>>>> but I guess this could be a bead at form level that. Probably for people
>>>>> happy with the current layout they could continue using it overriding the
>>>>> set of default beads in his app's css (hopefully).
>>>>>
>>>>>
>>>>>
>>>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
>>>>> piotrzarzycki21@gmail.com>) escribió:
>>>>>
>>>>>> Hi Carlos,
>>>>>>
>>>>>> If you think about changing name of the current component to FormDPCT
>>>>>> and write new one with old name - I prefer if you do just the opposite.
>>>>>> Name your new component in some way - once you will be ready - we will test
>>>>>> it and decide how it's working.
>>>>>>
>>>>>> IMO it should be done on the branch - if that's the case you can even
>>>>>> do not have name/rename, but just go ahead and change current Form.
>>>>>>
>>>>>> I do definitely wanted to see FormItem working as it is now + have
>>>>>> stacked Form item where label is on top - you can search - there were such
>>>>>> component in flex.
>>>>>>
>>>>>> I think also that our Form shouldn't contains to many pieces - Right
>>>>>> now I have label on the left, container on the right - it's taking too much
>>>>>> space - even if it will be super responsive.
>>>>>> I do work daily with Vuetify and this is good and non heavy example
>>>>>> how Forms should work and eventually look like [1]
>>>>>>
>>>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
>>>>>>
>>>>>> Thanks,
>>>>>> Piotr
>>>>>>
>>>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>>>>>> napisał(a):
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Jewel Form and FormItem specially, was implemented in a way that I
>>>>>>> never was happy. Also others like Piotr had problems doing certain things.
>>>>>>> So I was thinking of doing a big refactor, I think it will be
>>>>>>> important before we reach 1.0. But before doing this I was thinking first
>>>>>>> of leaving the actual Form and FormItem code available for some time as
>>>>>>> "deprecated" to be able to take the name for the new components. Another
>>>>>>> option could be to make the refactor over the actual control, but that will
>>>>>>> mean breaking actual code, so I think that will be a bad idea. Doing this
>>>>>>> way, you just need to rename both components in all your apps to the new
>>>>>>> name so that seems pretty easy so far.
>>>>>>>
>>>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>>>>>>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>>>>>>> same code, and FormItem and FormItemDPCT will have the same code too. If
>>>>>>> you have other proposals for the new name let me know.
>>>>>>>
>>>>>>> The refactor will do a better Form and FormItem responsive, so I
>>>>>>> think it is better to layout vertically (label then content controls) by
>>>>>>> default and take all available width in mobile screens. I think we'll need
>>>>>>> two layouts for the FormItem, one for layout label and content controls,
>>>>>>> and other for the content controls itself. Default will be all vertical.
>>>>>>>
>>>>>>> Then we'll be able to add other jewel layout beads to make all
>>>>>>> horizontal or just some parts.
>>>>>>> I think that way we'll have all flexibility.
>>>>>>>
>>>>>>> @Piotr (and others). I think it is the time to put in this thread
>>>>>>> anything you think I should consider in this refactor, so if you remember
>>>>>>> the main issues please take the time to log in this thread so I can have in
>>>>>>> mind.
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>> http://about.me/carlosrovira
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Piotr Zarzycki
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>> http://about.me/carlosrovira
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> Piotr Zarzycki
>>>>
>>>
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>>
>>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>
>
> --
>
> Piotr Zarzycki
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Thinking about Jewel Forms refactor

Posted by Hugo Ferreira <hf...@gmail.com>.
In resume, if we have horizontal, or vertical, as we shrink from
desktop-tablet to mobile, I think we should always go stacked through
responsiveness...

Absolutely.
No doubt on my opinion too.

Carlos Rovira <ca...@apache.org> escreveu no dia quarta, 9/09/2020
à(s) 14:54:

> Hi Hugo,
>
> thanks for the input.
>
> I think a "responsive" form will be very helpful. Mobile screens should
> always be stacked since there's no space to layout elements horizontally,
> and in a tiny mobile screen or label and controls are stacked, or we use a
> layout like Material or Vuetify where the label goes from "prompt" state to
> top (so finally stacked too).
>
> In resume, if we have horizontal, or vertical, as we shrink from
> desktop-tablet to mobile, I think we should always go stacked through
> responsiveness...
>
>
>
>
>
> El mié., 9 sept. 2020 a las 10:46, Hugo Ferreira (<hferreira.80@gmail.com
> >)
> escribió:
>
> > Let me add that I use both stacked and non stacked FormItem layout.
> > In my opinion the default does not matter.
> > Both should be supported via property (I'm old fashion) because it's a
> very
> > important property but I can live with beads too.
> > It's important that both are supported and when the browser is adjusted a
> > non stacked should be transformed in a stacke (that would be a nice to
> > have).
> >
> > Hugo Ferreira <hf...@gmail.com> escreveu no dia quarta, 9/09/2020
> > à(s) 09:32:
> >
> > > "What's more Hugo is using my extension as well - cause he expressed
> need
> > > of
> > > that -  I have send him off the list that one. I'm not the only person
> > who
> > > uses in their app stacked Form."
> > >
> > > Yes. I'm using your extension and it's working fine. Thank you very
> much
> > > for that.
> > > Please don't stop evolving the framework.
> > > When I update I know that it will break and I will search the
> > > replacement and fix it.
> > >
> > >
> > > Piotr Zarzycki <pi...@gmail.com> escreveu no dia quarta,
> > > 9/09/2020 à(s) 08:46:
> > >
> > >> What's more Hugo is using my extension as well - cause he expressed
> need
> > >> of
> > >> that -  I have send him off the list that one. I'm not the only person
> > who
> > >> uses in their app stacked Form.
> > >>
> > >> śr., 9 wrz 2020 o 09:45 Piotr Zarzycki <pi...@gmail.com>
> > >> napisał(a):
> > >>
> > >> > Yes I have more extension of current Form - I didn't commit this to
> > >> Royale
> > >> > in the results of our discussion a while ago. I have made
> significant
> > >> > changes to FormView to improve it and created stacked form layout.
> > >> >
> > >> > Anyway go ahead and do whatever you think - let me know and I will
> > apply
> > >> > your changes to our app using your branch.
> > >> >
> > >> > śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org>
> > >> > napisał(a):
> > >> >
> > >> >> Hi Piotr,
> > >> >>
> > >> >> don't understand all you said. You mean you have a stacked form
> > layout
> > >> >> now? that maybe is because you created your own extensions?
> > >> >>
> > >> >> I think the objective here should be to work on a final
> > implementation
> > >> >> that makes the Form/FormItem components behave in the most general
> > way
> > >> >> while it's easy to do other kinds of layouts. I'm afraid of people
> > >> having
> > >> >> problems as they start using it because the actual Form set is very
> > >> >> "particular". So it's not a problem for me to work on that to make
> it
> > >> as
> > >> >> more "general" as possible. As I end changes you can I'll try to
> give
> > >> a way
> > >> >> to make it work as before too, I hopefully think it could be
> > possible.
> > >> >> Other things could be if people have some personal extensions or
> > >> changes,
> > >> >> since that could make it more difficult for them to change to the
> new
> > >> one,
> > >> >> but I expect the new Form will have a better look and feel.
> > >> >>
> > >> >>
> > >> >> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
> > >> >> piotrzarzycki21@gmail.com>) escribió:
> > >> >>
> > >> >>> Carlos,
> > >> >>>
> > >> >>> If you won't do  stacked in the first shot - I won't use it - We
> > have
> > >> a
> > >> >>> lot of stacked stuff in our app. Without it it will just fail and
> > >> apart of
> > >> >>> changing code I will have to change more.. Sure if I have time I
> > will
> > >> help,
> > >> >>> but I cannot promise I will get time for this from company.
> > >> >>>
> > >> >>> Having stuff in branch prevents me from changing my app till
> > >> >>> everything work fully. - I can test stuf separately - instead deal
> > >> with
> > >> >>> some changes earlier in app and hold myself from using newest
> > nightly.
> > >> >>> Branch is the way to go in my opinion.
> > >> >>>
> > >> >>> Thanks,
> > >> >>> Piotr
> > >> >>>
> > >> >>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
> > >> >>> napisał(a):
> > >> >>>
> > >> >>>> Hi Piotr,
> > >> >>>>
> > >> >>>> (sending this to both user and dev since it affects to current
> > users
> > >> >>>> and we're discussing how to work on it)
> > >> >>>>
> > >> >>>> I prefer your approach to work in a branch over the current Form
> > >> code,
> > >> >>>> when finished it will require as well do some changes in final
> user
> > >> code so
> > >> >>>> in the end changes should be done one way or the other. it's ok
> for
> > >> me.
> > >> >>>> I'll be waiting a bit for any other input about this, and if
> nobody
> > >> >>>> opposite will go that route.
> > >> >>>>
> > >> >>>> I think the default will become "stacked" since I think is the
> most
> > >> >>>> typical/used, then we can have other flavours like the current
> > layout
> > >> >>>> (horizontal) and even the one show in vuetify or material where
> > >> labels
> > >> >>>> start as prompt and then shrink to the top of the control (for
> > >> textinput),
> > >> >>>> but I guess this could be a bead at form level that. Probably for
> > >> people
> > >> >>>> happy with the current layout they could continue using it
> > >> overriding the
> > >> >>>> set of default beads in his app's css (hopefully).
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
> > >> >>>> piotrzarzycki21@gmail.com>) escribió:
> > >> >>>>
> > >> >>>>> Hi Carlos,
> > >> >>>>>
> > >> >>>>> If you think about changing name of the current component to
> > >> FormDPCT
> > >> >>>>> and write new one with old name - I prefer if you do just the
> > >> opposite.
> > >> >>>>> Name your new component in some way - once you will be ready -
> we
> > >> will test
> > >> >>>>> it and decide how it's working.
> > >> >>>>>
> > >> >>>>> IMO it should be done on the branch - if that's the case you can
> > >> even
> > >> >>>>> do not have name/rename, but just go ahead and change current
> > Form.
> > >> >>>>>
> > >> >>>>> I do definitely wanted to see FormItem working as it is now +
> have
> > >> >>>>> stacked Form item where label is on top - you can search - there
> > >> were such
> > >> >>>>> component in flex.
> > >> >>>>>
> > >> >>>>> I think also that our Form shouldn't contains to many pieces -
> > Right
> > >> >>>>> now I have label on the left, container on the right - it's
> taking
> > >> too much
> > >> >>>>> space - even if it will be super responsive.
> > >> >>>>> I do work daily with Vuetify and this is good and non heavy
> > example
> > >> >>>>> how Forms should work and eventually look like [1]
> > >> >>>>>
> > >> >>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
> > >> >>>>>
> > >> >>>>> Thanks,
> > >> >>>>> Piotr
> > >> >>>>>
> > >> >>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
> > >> >>>>> napisał(a):
> > >> >>>>>
> > >> >>>>>> Hi all,
> > >> >>>>>>
> > >> >>>>>> Jewel Form and FormItem specially, was implemented in a way
> that
> > I
> > >> >>>>>> never was happy. Also others like Piotr had problems doing
> > certain
> > >> things.
> > >> >>>>>> So I was thinking of doing a big refactor, I think it will be
> > >> >>>>>> important before we reach 1.0. But before doing this I was
> > >> thinking first
> > >> >>>>>> of leaving the actual Form and FormItem code available for some
> > >> time as
> > >> >>>>>> "deprecated" to be able to take the name for the new
> components.
> > >> Another
> > >> >>>>>> option could be to make the refactor over the actual control,
> but
> > >> that will
> > >> >>>>>> mean breaking actual code, so I think that will be a bad idea.
> > >> Doing this
> > >> >>>>>> way, you just need to rename both components in all your apps
> to
> > >> the new
> > >> >>>>>> name so that seems pretty easy so far.
> > >> >>>>>>
> > >> >>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
> > >> >>>>>> "Deprecated"). That means that initially, Form and FormDPCT
> will
> > >> have the
> > >> >>>>>> same code, and FormItem and FormItemDPCT will have the same
> code
> > >> too. If
> > >> >>>>>> you have other proposals for the new name let me know.
> > >> >>>>>>
> > >> >>>>>> The refactor will do a better Form and FormItem responsive, so
> I
> > >> >>>>>> think it is better to layout vertically (label then content
> > >> controls) by
> > >> >>>>>> default and take all available width in mobile screens. I think
> > >> we'll need
> > >> >>>>>> two layouts for the FormItem, one for layout label and content
> > >> controls,
> > >> >>>>>> and other for the content controls itself. Default will be all
> > >> vertical.
> > >> >>>>>>
> > >> >>>>>> Then we'll be able to add other jewel layout beads to make all
> > >> >>>>>> horizontal or just some parts.
> > >> >>>>>> I think that way we'll have all flexibility.
> > >> >>>>>>
> > >> >>>>>> @Piotr (and others). I think it is the time to put in this
> thread
> > >> >>>>>> anything you think I should consider in this refactor, so if
> you
> > >> remember
> > >> >>>>>> the main issues please take the time to log in this thread so I
> > >> can have in
> > >> >>>>>> mind.
> > >> >>>>>>
> > >> >>>>>> --
> > >> >>>>>> Carlos Rovira
> > >> >>>>>> http://about.me/carlosrovira
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>> --
> > >> >>>>>
> > >> >>>>> Piotr Zarzycki
> > >> >>>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> --
> > >> >>>> Carlos Rovira
> > >> >>>> http://about.me/carlosrovira
> > >> >>>>
> > >> >>>>
> > >> >>>
> > >> >>> --
> > >> >>>
> > >> >>> Piotr Zarzycki
> > >> >>>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Carlos Rovira
> > >> >> http://about.me/carlosrovira
> > >> >>
> > >> >>
> > >> >
> > >> > --
> > >> >
> > >> > Piotr Zarzycki
> > >> >
> > >>
> > >>
> > >> --
> > >>
> > >> Piotr Zarzycki
> > >>
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>

Re: Thinking about Jewel Forms refactor

Posted by Carlos Rovira <ca...@apache.org>.
Hi Hugo,

thanks for the input.

I think a "responsive" form will be very helpful. Mobile screens should
always be stacked since there's no space to layout elements horizontally,
and in a tiny mobile screen or label and controls are stacked, or we use a
layout like Material or Vuetify where the label goes from "prompt" state to
top (so finally stacked too).

In resume, if we have horizontal, or vertical, as we shrink from
desktop-tablet to mobile, I think we should always go stacked through
responsiveness...





El mié., 9 sept. 2020 a las 10:46, Hugo Ferreira (<hf...@gmail.com>)
escribió:

> Let me add that I use both stacked and non stacked FormItem layout.
> In my opinion the default does not matter.
> Both should be supported via property (I'm old fashion) because it's a very
> important property but I can live with beads too.
> It's important that both are supported and when the browser is adjusted a
> non stacked should be transformed in a stacke (that would be a nice to
> have).
>
> Hugo Ferreira <hf...@gmail.com> escreveu no dia quarta, 9/09/2020
> à(s) 09:32:
>
> > "What's more Hugo is using my extension as well - cause he expressed need
> > of
> > that -  I have send him off the list that one. I'm not the only person
> who
> > uses in their app stacked Form."
> >
> > Yes. I'm using your extension and it's working fine. Thank you very much
> > for that.
> > Please don't stop evolving the framework.
> > When I update I know that it will break and I will search the
> > replacement and fix it.
> >
> >
> > Piotr Zarzycki <pi...@gmail.com> escreveu no dia quarta,
> > 9/09/2020 à(s) 08:46:
> >
> >> What's more Hugo is using my extension as well - cause he expressed need
> >> of
> >> that -  I have send him off the list that one. I'm not the only person
> who
> >> uses in their app stacked Form.
> >>
> >> śr., 9 wrz 2020 o 09:45 Piotr Zarzycki <pi...@gmail.com>
> >> napisał(a):
> >>
> >> > Yes I have more extension of current Form - I didn't commit this to
> >> Royale
> >> > in the results of our discussion a while ago. I have made significant
> >> > changes to FormView to improve it and created stacked form layout.
> >> >
> >> > Anyway go ahead and do whatever you think - let me know and I will
> apply
> >> > your changes to our app using your branch.
> >> >
> >> > śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org>
> >> > napisał(a):
> >> >
> >> >> Hi Piotr,
> >> >>
> >> >> don't understand all you said. You mean you have a stacked form
> layout
> >> >> now? that maybe is because you created your own extensions?
> >> >>
> >> >> I think the objective here should be to work on a final
> implementation
> >> >> that makes the Form/FormItem components behave in the most general
> way
> >> >> while it's easy to do other kinds of layouts. I'm afraid of people
> >> having
> >> >> problems as they start using it because the actual Form set is very
> >> >> "particular". So it's not a problem for me to work on that to make it
> >> as
> >> >> more "general" as possible. As I end changes you can I'll try to give
> >> a way
> >> >> to make it work as before too, I hopefully think it could be
> possible.
> >> >> Other things could be if people have some personal extensions or
> >> changes,
> >> >> since that could make it more difficult for them to change to the new
> >> one,
> >> >> but I expect the new Form will have a better look and feel.
> >> >>
> >> >>
> >> >> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
> >> >> piotrzarzycki21@gmail.com>) escribió:
> >> >>
> >> >>> Carlos,
> >> >>>
> >> >>> If you won't do  stacked in the first shot - I won't use it - We
> have
> >> a
> >> >>> lot of stacked stuff in our app. Without it it will just fail and
> >> apart of
> >> >>> changing code I will have to change more.. Sure if I have time I
> will
> >> help,
> >> >>> but I cannot promise I will get time for this from company.
> >> >>>
> >> >>> Having stuff in branch prevents me from changing my app till
> >> >>> everything work fully. - I can test stuf separately - instead deal
> >> with
> >> >>> some changes earlier in app and hold myself from using newest
> nightly.
> >> >>> Branch is the way to go in my opinion.
> >> >>>
> >> >>> Thanks,
> >> >>> Piotr
> >> >>>
> >> >>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
> >> >>> napisał(a):
> >> >>>
> >> >>>> Hi Piotr,
> >> >>>>
> >> >>>> (sending this to both user and dev since it affects to current
> users
> >> >>>> and we're discussing how to work on it)
> >> >>>>
> >> >>>> I prefer your approach to work in a branch over the current Form
> >> code,
> >> >>>> when finished it will require as well do some changes in final user
> >> code so
> >> >>>> in the end changes should be done one way or the other. it's ok for
> >> me.
> >> >>>> I'll be waiting a bit for any other input about this, and if nobody
> >> >>>> opposite will go that route.
> >> >>>>
> >> >>>> I think the default will become "stacked" since I think is the most
> >> >>>> typical/used, then we can have other flavours like the current
> layout
> >> >>>> (horizontal) and even the one show in vuetify or material where
> >> labels
> >> >>>> start as prompt and then shrink to the top of the control (for
> >> textinput),
> >> >>>> but I guess this could be a bead at form level that. Probably for
> >> people
> >> >>>> happy with the current layout they could continue using it
> >> overriding the
> >> >>>> set of default beads in his app's css (hopefully).
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
> >> >>>> piotrzarzycki21@gmail.com>) escribió:
> >> >>>>
> >> >>>>> Hi Carlos,
> >> >>>>>
> >> >>>>> If you think about changing name of the current component to
> >> FormDPCT
> >> >>>>> and write new one with old name - I prefer if you do just the
> >> opposite.
> >> >>>>> Name your new component in some way - once you will be ready - we
> >> will test
> >> >>>>> it and decide how it's working.
> >> >>>>>
> >> >>>>> IMO it should be done on the branch - if that's the case you can
> >> even
> >> >>>>> do not have name/rename, but just go ahead and change current
> Form.
> >> >>>>>
> >> >>>>> I do definitely wanted to see FormItem working as it is now + have
> >> >>>>> stacked Form item where label is on top - you can search - there
> >> were such
> >> >>>>> component in flex.
> >> >>>>>
> >> >>>>> I think also that our Form shouldn't contains to many pieces -
> Right
> >> >>>>> now I have label on the left, container on the right - it's taking
> >> too much
> >> >>>>> space - even if it will be super responsive.
> >> >>>>> I do work daily with Vuetify and this is good and non heavy
> example
> >> >>>>> how Forms should work and eventually look like [1]
> >> >>>>>
> >> >>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
> >> >>>>>
> >> >>>>> Thanks,
> >> >>>>> Piotr
> >> >>>>>
> >> >>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
> >> >>>>> napisał(a):
> >> >>>>>
> >> >>>>>> Hi all,
> >> >>>>>>
> >> >>>>>> Jewel Form and FormItem specially, was implemented in a way that
> I
> >> >>>>>> never was happy. Also others like Piotr had problems doing
> certain
> >> things.
> >> >>>>>> So I was thinking of doing a big refactor, I think it will be
> >> >>>>>> important before we reach 1.0. But before doing this I was
> >> thinking first
> >> >>>>>> of leaving the actual Form and FormItem code available for some
> >> time as
> >> >>>>>> "deprecated" to be able to take the name for the new components.
> >> Another
> >> >>>>>> option could be to make the refactor over the actual control, but
> >> that will
> >> >>>>>> mean breaking actual code, so I think that will be a bad idea.
> >> Doing this
> >> >>>>>> way, you just need to rename both components in all your apps to
> >> the new
> >> >>>>>> name so that seems pretty easy so far.
> >> >>>>>>
> >> >>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
> >> >>>>>> "Deprecated"). That means that initially, Form and FormDPCT will
> >> have the
> >> >>>>>> same code, and FormItem and FormItemDPCT will have the same code
> >> too. If
> >> >>>>>> you have other proposals for the new name let me know.
> >> >>>>>>
> >> >>>>>> The refactor will do a better Form and FormItem responsive, so I
> >> >>>>>> think it is better to layout vertically (label then content
> >> controls) by
> >> >>>>>> default and take all available width in mobile screens. I think
> >> we'll need
> >> >>>>>> two layouts for the FormItem, one for layout label and content
> >> controls,
> >> >>>>>> and other for the content controls itself. Default will be all
> >> vertical.
> >> >>>>>>
> >> >>>>>> Then we'll be able to add other jewel layout beads to make all
> >> >>>>>> horizontal or just some parts.
> >> >>>>>> I think that way we'll have all flexibility.
> >> >>>>>>
> >> >>>>>> @Piotr (and others). I think it is the time to put in this thread
> >> >>>>>> anything you think I should consider in this refactor, so if you
> >> remember
> >> >>>>>> the main issues please take the time to log in this thread so I
> >> can have in
> >> >>>>>> mind.
> >> >>>>>>
> >> >>>>>> --
> >> >>>>>> Carlos Rovira
> >> >>>>>> http://about.me/carlosrovira
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>>
> >> >>>>> Piotr Zarzycki
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> Carlos Rovira
> >> >>>> http://about.me/carlosrovira
> >> >>>>
> >> >>>>
> >> >>>
> >> >>> --
> >> >>>
> >> >>> Piotr Zarzycki
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> Carlos Rovira
> >> >> http://about.me/carlosrovira
> >> >>
> >> >>
> >> >
> >> > --
> >> >
> >> > Piotr Zarzycki
> >> >
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Thinking about Jewel Forms refactor

Posted by Hugo Ferreira <hf...@gmail.com>.
Let me add that I use both stacked and non stacked FormItem layout.
In my opinion the default does not matter.
Both should be supported via property (I'm old fashion) because it's a very
important property but I can live with beads too.
It's important that both are supported and when the browser is adjusted a
non stacked should be transformed in a stacke (that would be a nice to
have).

Hugo Ferreira <hf...@gmail.com> escreveu no dia quarta, 9/09/2020
à(s) 09:32:

> "What's more Hugo is using my extension as well - cause he expressed need
> of
> that -  I have send him off the list that one. I'm not the only person who
> uses in their app stacked Form."
>
> Yes. I'm using your extension and it's working fine. Thank you very much
> for that.
> Please don't stop evolving the framework.
> When I update I know that it will break and I will search the
> replacement and fix it.
>
>
> Piotr Zarzycki <pi...@gmail.com> escreveu no dia quarta,
> 9/09/2020 à(s) 08:46:
>
>> What's more Hugo is using my extension as well - cause he expressed need
>> of
>> that -  I have send him off the list that one. I'm not the only person who
>> uses in their app stacked Form.
>>
>> śr., 9 wrz 2020 o 09:45 Piotr Zarzycki <pi...@gmail.com>
>> napisał(a):
>>
>> > Yes I have more extension of current Form - I didn't commit this to
>> Royale
>> > in the results of our discussion a while ago. I have made significant
>> > changes to FormView to improve it and created stacked form layout.
>> >
>> > Anyway go ahead and do whatever you think - let me know and I will apply
>> > your changes to our app using your branch.
>> >
>> > śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org>
>> > napisał(a):
>> >
>> >> Hi Piotr,
>> >>
>> >> don't understand all you said. You mean you have a stacked form layout
>> >> now? that maybe is because you created your own extensions?
>> >>
>> >> I think the objective here should be to work on a final implementation
>> >> that makes the Form/FormItem components behave in the most general way
>> >> while it's easy to do other kinds of layouts. I'm afraid of people
>> having
>> >> problems as they start using it because the actual Form set is very
>> >> "particular". So it's not a problem for me to work on that to make it
>> as
>> >> more "general" as possible. As I end changes you can I'll try to give
>> a way
>> >> to make it work as before too, I hopefully think it could be possible.
>> >> Other things could be if people have some personal extensions or
>> changes,
>> >> since that could make it more difficult for them to change to the new
>> one,
>> >> but I expect the new Form will have a better look and feel.
>> >>
>> >>
>> >> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
>> >> piotrzarzycki21@gmail.com>) escribió:
>> >>
>> >>> Carlos,
>> >>>
>> >>> If you won't do  stacked in the first shot - I won't use it - We have
>> a
>> >>> lot of stacked stuff in our app. Without it it will just fail and
>> apart of
>> >>> changing code I will have to change more.. Sure if I have time I will
>> help,
>> >>> but I cannot promise I will get time for this from company.
>> >>>
>> >>> Having stuff in branch prevents me from changing my app till
>> >>> everything work fully. - I can test stuf separately - instead deal
>> with
>> >>> some changes earlier in app and hold myself from using newest nightly.
>> >>> Branch is the way to go in my opinion.
>> >>>
>> >>> Thanks,
>> >>> Piotr
>> >>>
>> >>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
>> >>> napisał(a):
>> >>>
>> >>>> Hi Piotr,
>> >>>>
>> >>>> (sending this to both user and dev since it affects to current users
>> >>>> and we're discussing how to work on it)
>> >>>>
>> >>>> I prefer your approach to work in a branch over the current Form
>> code,
>> >>>> when finished it will require as well do some changes in final user
>> code so
>> >>>> in the end changes should be done one way or the other. it's ok for
>> me.
>> >>>> I'll be waiting a bit for any other input about this, and if nobody
>> >>>> opposite will go that route.
>> >>>>
>> >>>> I think the default will become "stacked" since I think is the most
>> >>>> typical/used, then we can have other flavours like the current layout
>> >>>> (horizontal) and even the one show in vuetify or material where
>> labels
>> >>>> start as prompt and then shrink to the top of the control (for
>> textinput),
>> >>>> but I guess this could be a bead at form level that. Probably for
>> people
>> >>>> happy with the current layout they could continue using it
>> overriding the
>> >>>> set of default beads in his app's css (hopefully).
>> >>>>
>> >>>>
>> >>>>
>> >>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
>> >>>> piotrzarzycki21@gmail.com>) escribió:
>> >>>>
>> >>>>> Hi Carlos,
>> >>>>>
>> >>>>> If you think about changing name of the current component to
>> FormDPCT
>> >>>>> and write new one with old name - I prefer if you do just the
>> opposite.
>> >>>>> Name your new component in some way - once you will be ready - we
>> will test
>> >>>>> it and decide how it's working.
>> >>>>>
>> >>>>> IMO it should be done on the branch - if that's the case you can
>> even
>> >>>>> do not have name/rename, but just go ahead and change current Form.
>> >>>>>
>> >>>>> I do definitely wanted to see FormItem working as it is now + have
>> >>>>> stacked Form item where label is on top - you can search - there
>> were such
>> >>>>> component in flex.
>> >>>>>
>> >>>>> I think also that our Form shouldn't contains to many pieces - Right
>> >>>>> now I have label on the left, container on the right - it's taking
>> too much
>> >>>>> space - even if it will be super responsive.
>> >>>>> I do work daily with Vuetify and this is good and non heavy example
>> >>>>> how Forms should work and eventually look like [1]
>> >>>>>
>> >>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Piotr
>> >>>>>
>> >>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>> >>>>> napisał(a):
>> >>>>>
>> >>>>>> Hi all,
>> >>>>>>
>> >>>>>> Jewel Form and FormItem specially, was implemented in a way that I
>> >>>>>> never was happy. Also others like Piotr had problems doing certain
>> things.
>> >>>>>> So I was thinking of doing a big refactor, I think it will be
>> >>>>>> important before we reach 1.0. But before doing this I was
>> thinking first
>> >>>>>> of leaving the actual Form and FormItem code available for some
>> time as
>> >>>>>> "deprecated" to be able to take the name for the new components.
>> Another
>> >>>>>> option could be to make the refactor over the actual control, but
>> that will
>> >>>>>> mean breaking actual code, so I think that will be a bad idea.
>> Doing this
>> >>>>>> way, you just need to rename both components in all your apps to
>> the new
>> >>>>>> name so that seems pretty easy so far.
>> >>>>>>
>> >>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>> >>>>>> "Deprecated"). That means that initially, Form and FormDPCT will
>> have the
>> >>>>>> same code, and FormItem and FormItemDPCT will have the same code
>> too. If
>> >>>>>> you have other proposals for the new name let me know.
>> >>>>>>
>> >>>>>> The refactor will do a better Form and FormItem responsive, so I
>> >>>>>> think it is better to layout vertically (label then content
>> controls) by
>> >>>>>> default and take all available width in mobile screens. I think
>> we'll need
>> >>>>>> two layouts for the FormItem, one for layout label and content
>> controls,
>> >>>>>> and other for the content controls itself. Default will be all
>> vertical.
>> >>>>>>
>> >>>>>> Then we'll be able to add other jewel layout beads to make all
>> >>>>>> horizontal or just some parts.
>> >>>>>> I think that way we'll have all flexibility.
>> >>>>>>
>> >>>>>> @Piotr (and others). I think it is the time to put in this thread
>> >>>>>> anything you think I should consider in this refactor, so if you
>> remember
>> >>>>>> the main issues please take the time to log in this thread so I
>> can have in
>> >>>>>> mind.
>> >>>>>>
>> >>>>>> --
>> >>>>>> Carlos Rovira
>> >>>>>> http://about.me/carlosrovira
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>> --
>> >>>>>
>> >>>>> Piotr Zarzycki
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Carlos Rovira
>> >>>> http://about.me/carlosrovira
>> >>>>
>> >>>>
>> >>>
>> >>> --
>> >>>
>> >>> Piotr Zarzycki
>> >>>
>> >>
>> >>
>> >> --
>> >> Carlos Rovira
>> >> http://about.me/carlosrovira
>> >>
>> >>
>> >
>> > --
>> >
>> > Piotr Zarzycki
>> >
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>

Re: Thinking about Jewel Forms refactor

Posted by Hugo Ferreira <hf...@gmail.com>.
"What's more Hugo is using my extension as well - cause he expressed need of
that -  I have send him off the list that one. I'm not the only person who
uses in their app stacked Form."

Yes. I'm using your extension and it's working fine. Thank you very much
for that.
Please don't stop evolving the framework.
When I update I know that it will break and I will search the
replacement and fix it.


Piotr Zarzycki <pi...@gmail.com> escreveu no dia quarta,
9/09/2020 à(s) 08:46:

> What's more Hugo is using my extension as well - cause he expressed need of
> that -  I have send him off the list that one. I'm not the only person who
> uses in their app stacked Form.
>
> śr., 9 wrz 2020 o 09:45 Piotr Zarzycki <pi...@gmail.com>
> napisał(a):
>
> > Yes I have more extension of current Form - I didn't commit this to
> Royale
> > in the results of our discussion a while ago. I have made significant
> > changes to FormView to improve it and created stacked form layout.
> >
> > Anyway go ahead and do whatever you think - let me know and I will apply
> > your changes to our app using your branch.
> >
> > śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org>
> > napisał(a):
> >
> >> Hi Piotr,
> >>
> >> don't understand all you said. You mean you have a stacked form layout
> >> now? that maybe is because you created your own extensions?
> >>
> >> I think the objective here should be to work on a final implementation
> >> that makes the Form/FormItem components behave in the most general way
> >> while it's easy to do other kinds of layouts. I'm afraid of people
> having
> >> problems as they start using it because the actual Form set is very
> >> "particular". So it's not a problem for me to work on that to make it as
> >> more "general" as possible. As I end changes you can I'll try to give a
> way
> >> to make it work as before too, I hopefully think it could be possible.
> >> Other things could be if people have some personal extensions or
> changes,
> >> since that could make it more difficult for them to change to the new
> one,
> >> but I expect the new Form will have a better look and feel.
> >>
> >>
> >> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
> >> piotrzarzycki21@gmail.com>) escribió:
> >>
> >>> Carlos,
> >>>
> >>> If you won't do  stacked in the first shot - I won't use it - We have a
> >>> lot of stacked stuff in our app. Without it it will just fail and
> apart of
> >>> changing code I will have to change more.. Sure if I have time I will
> help,
> >>> but I cannot promise I will get time for this from company.
> >>>
> >>> Having stuff in branch prevents me from changing my app till
> >>> everything work fully. - I can test stuf separately - instead deal with
> >>> some changes earlier in app and hold myself from using newest nightly.
> >>> Branch is the way to go in my opinion.
> >>>
> >>> Thanks,
> >>> Piotr
> >>>
> >>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
> >>> napisał(a):
> >>>
> >>>> Hi Piotr,
> >>>>
> >>>> (sending this to both user and dev since it affects to current users
> >>>> and we're discussing how to work on it)
> >>>>
> >>>> I prefer your approach to work in a branch over the current Form code,
> >>>> when finished it will require as well do some changes in final user
> code so
> >>>> in the end changes should be done one way or the other. it's ok for
> me.
> >>>> I'll be waiting a bit for any other input about this, and if nobody
> >>>> opposite will go that route.
> >>>>
> >>>> I think the default will become "stacked" since I think is the most
> >>>> typical/used, then we can have other flavours like the current layout
> >>>> (horizontal) and even the one show in vuetify or material where labels
> >>>> start as prompt and then shrink to the top of the control (for
> textinput),
> >>>> but I guess this could be a bead at form level that. Probably for
> people
> >>>> happy with the current layout they could continue using it overriding
> the
> >>>> set of default beads in his app's css (hopefully).
> >>>>
> >>>>
> >>>>
> >>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
> >>>> piotrzarzycki21@gmail.com>) escribió:
> >>>>
> >>>>> Hi Carlos,
> >>>>>
> >>>>> If you think about changing name of the current component to FormDPCT
> >>>>> and write new one with old name - I prefer if you do just the
> opposite.
> >>>>> Name your new component in some way - once you will be ready - we
> will test
> >>>>> it and decide how it's working.
> >>>>>
> >>>>> IMO it should be done on the branch - if that's the case you can even
> >>>>> do not have name/rename, but just go ahead and change current Form.
> >>>>>
> >>>>> I do definitely wanted to see FormItem working as it is now + have
> >>>>> stacked Form item where label is on top - you can search - there
> were such
> >>>>> component in flex.
> >>>>>
> >>>>> I think also that our Form shouldn't contains to many pieces - Right
> >>>>> now I have label on the left, container on the right - it's taking
> too much
> >>>>> space - even if it will be super responsive.
> >>>>> I do work daily with Vuetify and this is good and non heavy example
> >>>>> how Forms should work and eventually look like [1]
> >>>>>
> >>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
> >>>>>
> >>>>> Thanks,
> >>>>> Piotr
> >>>>>
> >>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
> >>>>> napisał(a):
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> Jewel Form and FormItem specially, was implemented in a way that I
> >>>>>> never was happy. Also others like Piotr had problems doing certain
> things.
> >>>>>> So I was thinking of doing a big refactor, I think it will be
> >>>>>> important before we reach 1.0. But before doing this I was thinking
> first
> >>>>>> of leaving the actual Form and FormItem code available for some
> time as
> >>>>>> "deprecated" to be able to take the name for the new components.
> Another
> >>>>>> option could be to make the refactor over the actual control, but
> that will
> >>>>>> mean breaking actual code, so I think that will be a bad idea.
> Doing this
> >>>>>> way, you just need to rename both components in all your apps to
> the new
> >>>>>> name so that seems pretty easy so far.
> >>>>>>
> >>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
> >>>>>> "Deprecated"). That means that initially, Form and FormDPCT will
> have the
> >>>>>> same code, and FormItem and FormItemDPCT will have the same code
> too. If
> >>>>>> you have other proposals for the new name let me know.
> >>>>>>
> >>>>>> The refactor will do a better Form and FormItem responsive, so I
> >>>>>> think it is better to layout vertically (label then content
> controls) by
> >>>>>> default and take all available width in mobile screens. I think
> we'll need
> >>>>>> two layouts for the FormItem, one for layout label and content
> controls,
> >>>>>> and other for the content controls itself. Default will be all
> vertical.
> >>>>>>
> >>>>>> Then we'll be able to add other jewel layout beads to make all
> >>>>>> horizontal or just some parts.
> >>>>>> I think that way we'll have all flexibility.
> >>>>>>
> >>>>>> @Piotr (and others). I think it is the time to put in this thread
> >>>>>> anything you think I should consider in this refactor, so if you
> remember
> >>>>>> the main issues please take the time to log in this thread so I can
> have in
> >>>>>> mind.
> >>>>>>
> >>>>>> --
> >>>>>> Carlos Rovira
> >>>>>> http://about.me/carlosrovira
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Piotr Zarzycki
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>> http://about.me/carlosrovira
> >>>>
> >>>>
> >>>
> >>> --
> >>>
> >>> Piotr Zarzycki
> >>>
> >>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >>
> >>
> >
> > --
> >
> > Piotr Zarzycki
> >
>
>
> --
>
> Piotr Zarzycki
>

Re: Thinking about Jewel Forms refactor

Posted by Carlos Rovira <ca...@apache.org>.
Ok, that's what I want to avoid, having unofficial extensions for something
that we should provide out of the box.
We need to provide the flexibility to do all that kind of layouts and then
users could extend from that to adapt to some particular less generalistic
use cases, but the components should be sufficient 99% of the time.


El mié., 9 sept. 2020 a las 9:46, Piotr Zarzycki (<pi...@gmail.com>)
escribió:

> What's more Hugo is using my extension as well - cause he expressed need
> of that -  I have send him off the list that one. I'm not the only person
> who uses in their app stacked Form.
>
> śr., 9 wrz 2020 o 09:45 Piotr Zarzycki <pi...@gmail.com>
> napisał(a):
>
>> Yes I have more extension of current Form - I didn't commit this to
>> Royale in the results of our discussion a while ago. I have made
>> significant changes to FormView to improve it and created stacked form
>> layout.
>>
>> Anyway go ahead and do whatever you think - let me know and I will apply
>> your changes to our app using your branch.
>>
>> śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org>
>> napisał(a):
>>
>>> Hi Piotr,
>>>
>>> don't understand all you said. You mean you have a stacked form layout
>>> now? that maybe is because you created your own extensions?
>>>
>>> I think the objective here should be to work on a final implementation
>>> that makes the Form/FormItem components behave in the most general way
>>> while it's easy to do other kinds of layouts. I'm afraid of people having
>>> problems as they start using it because the actual Form set is very
>>> "particular". So it's not a problem for me to work on that to make it as
>>> more "general" as possible. As I end changes you can I'll try to give a way
>>> to make it work as before too, I hopefully think it could be possible.
>>> Other things could be if people have some personal extensions or changes,
>>> since that could make it more difficult for them to change to the new one,
>>> but I expect the new Form will have a better look and feel.
>>>
>>>
>>> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
>>> piotrzarzycki21@gmail.com>) escribió:
>>>
>>>> Carlos,
>>>>
>>>> If you won't do  stacked in the first shot - I won't use it - We have a
>>>> lot of stacked stuff in our app. Without it it will just fail and apart of
>>>> changing code I will have to change more.. Sure if I have time I will help,
>>>> but I cannot promise I will get time for this from company.
>>>>
>>>> Having stuff in branch prevents me from changing my app till
>>>> everything work fully. - I can test stuf separately - instead deal with
>>>> some changes earlier in app and hold myself from using newest nightly.
>>>> Branch is the way to go in my opinion.
>>>>
>>>> Thanks,
>>>> Piotr
>>>>
>>>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
>>>> napisał(a):
>>>>
>>>>> Hi Piotr,
>>>>>
>>>>> (sending this to both user and dev since it affects to current users
>>>>> and we're discussing how to work on it)
>>>>>
>>>>> I prefer your approach to work in a branch over the current Form code,
>>>>> when finished it will require as well do some changes in final user code so
>>>>> in the end changes should be done one way or the other. it's ok for me.
>>>>> I'll be waiting a bit for any other input about this, and if nobody
>>>>> opposite will go that route.
>>>>>
>>>>> I think the default will become "stacked" since I think is the most
>>>>> typical/used, then we can have other flavours like the current layout
>>>>> (horizontal) and even the one show in vuetify or material where labels
>>>>> start as prompt and then shrink to the top of the control (for textinput),
>>>>> but I guess this could be a bead at form level that. Probably for people
>>>>> happy with the current layout they could continue using it overriding the
>>>>> set of default beads in his app's css (hopefully).
>>>>>
>>>>>
>>>>>
>>>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
>>>>> piotrzarzycki21@gmail.com>) escribió:
>>>>>
>>>>>> Hi Carlos,
>>>>>>
>>>>>> If you think about changing name of the current component to FormDPCT
>>>>>> and write new one with old name - I prefer if you do just the opposite.
>>>>>> Name your new component in some way - once you will be ready - we will test
>>>>>> it and decide how it's working.
>>>>>>
>>>>>> IMO it should be done on the branch - if that's the case you can even
>>>>>> do not have name/rename, but just go ahead and change current Form.
>>>>>>
>>>>>> I do definitely wanted to see FormItem working as it is now + have
>>>>>> stacked Form item where label is on top - you can search - there were such
>>>>>> component in flex.
>>>>>>
>>>>>> I think also that our Form shouldn't contains to many pieces - Right
>>>>>> now I have label on the left, container on the right - it's taking too much
>>>>>> space - even if it will be super responsive.
>>>>>> I do work daily with Vuetify and this is good and non heavy example
>>>>>> how Forms should work and eventually look like [1]
>>>>>>
>>>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
>>>>>>
>>>>>> Thanks,
>>>>>> Piotr
>>>>>>
>>>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>>>>>> napisał(a):
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Jewel Form and FormItem specially, was implemented in a way that I
>>>>>>> never was happy. Also others like Piotr had problems doing certain things.
>>>>>>> So I was thinking of doing a big refactor, I think it will be
>>>>>>> important before we reach 1.0. But before doing this I was thinking first
>>>>>>> of leaving the actual Form and FormItem code available for some time as
>>>>>>> "deprecated" to be able to take the name for the new components. Another
>>>>>>> option could be to make the refactor over the actual control, but that will
>>>>>>> mean breaking actual code, so I think that will be a bad idea. Doing this
>>>>>>> way, you just need to rename both components in all your apps to the new
>>>>>>> name so that seems pretty easy so far.
>>>>>>>
>>>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>>>>>>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>>>>>>> same code, and FormItem and FormItemDPCT will have the same code too. If
>>>>>>> you have other proposals for the new name let me know.
>>>>>>>
>>>>>>> The refactor will do a better Form and FormItem responsive, so I
>>>>>>> think it is better to layout vertically (label then content controls) by
>>>>>>> default and take all available width in mobile screens. I think we'll need
>>>>>>> two layouts for the FormItem, one for layout label and content controls,
>>>>>>> and other for the content controls itself. Default will be all vertical.
>>>>>>>
>>>>>>> Then we'll be able to add other jewel layout beads to make all
>>>>>>> horizontal or just some parts.
>>>>>>> I think that way we'll have all flexibility.
>>>>>>>
>>>>>>> @Piotr (and others). I think it is the time to put in this thread
>>>>>>> anything you think I should consider in this refactor, so if you remember
>>>>>>> the main issues please take the time to log in this thread so I can have in
>>>>>>> mind.
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>> http://about.me/carlosrovira
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Piotr Zarzycki
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>> http://about.me/carlosrovira
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> Piotr Zarzycki
>>>>
>>>
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>>
>>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>
>
> --
>
> Piotr Zarzycki
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Thinking about Jewel Forms refactor

Posted by Piotr Zarzycki <pi...@gmail.com>.
What's more Hugo is using my extension as well - cause he expressed need of
that -  I have send him off the list that one. I'm not the only person who
uses in their app stacked Form.

śr., 9 wrz 2020 o 09:45 Piotr Zarzycki <pi...@gmail.com>
napisał(a):

> Yes I have more extension of current Form - I didn't commit this to Royale
> in the results of our discussion a while ago. I have made significant
> changes to FormView to improve it and created stacked form layout.
>
> Anyway go ahead and do whatever you think - let me know and I will apply
> your changes to our app using your branch.
>
> śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
>> Hi Piotr,
>>
>> don't understand all you said. You mean you have a stacked form layout
>> now? that maybe is because you created your own extensions?
>>
>> I think the objective here should be to work on a final implementation
>> that makes the Form/FormItem components behave in the most general way
>> while it's easy to do other kinds of layouts. I'm afraid of people having
>> problems as they start using it because the actual Form set is very
>> "particular". So it's not a problem for me to work on that to make it as
>> more "general" as possible. As I end changes you can I'll try to give a way
>> to make it work as before too, I hopefully think it could be possible.
>> Other things could be if people have some personal extensions or changes,
>> since that could make it more difficult for them to change to the new one,
>> but I expect the new Form will have a better look and feel.
>>
>>
>> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
>> piotrzarzycki21@gmail.com>) escribió:
>>
>>> Carlos,
>>>
>>> If you won't do  stacked in the first shot - I won't use it - We have a
>>> lot of stacked stuff in our app. Without it it will just fail and apart of
>>> changing code I will have to change more.. Sure if I have time I will help,
>>> but I cannot promise I will get time for this from company.
>>>
>>> Having stuff in branch prevents me from changing my app till
>>> everything work fully. - I can test stuf separately - instead deal with
>>> some changes earlier in app and hold myself from using newest nightly.
>>> Branch is the way to go in my opinion.
>>>
>>> Thanks,
>>> Piotr
>>>
>>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
>>> napisał(a):
>>>
>>>> Hi Piotr,
>>>>
>>>> (sending this to both user and dev since it affects to current users
>>>> and we're discussing how to work on it)
>>>>
>>>> I prefer your approach to work in a branch over the current Form code,
>>>> when finished it will require as well do some changes in final user code so
>>>> in the end changes should be done one way or the other. it's ok for me.
>>>> I'll be waiting a bit for any other input about this, and if nobody
>>>> opposite will go that route.
>>>>
>>>> I think the default will become "stacked" since I think is the most
>>>> typical/used, then we can have other flavours like the current layout
>>>> (horizontal) and even the one show in vuetify or material where labels
>>>> start as prompt and then shrink to the top of the control (for textinput),
>>>> but I guess this could be a bead at form level that. Probably for people
>>>> happy with the current layout they could continue using it overriding the
>>>> set of default beads in his app's css (hopefully).
>>>>
>>>>
>>>>
>>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
>>>> piotrzarzycki21@gmail.com>) escribió:
>>>>
>>>>> Hi Carlos,
>>>>>
>>>>> If you think about changing name of the current component to FormDPCT
>>>>> and write new one with old name - I prefer if you do just the opposite.
>>>>> Name your new component in some way - once you will be ready - we will test
>>>>> it and decide how it's working.
>>>>>
>>>>> IMO it should be done on the branch - if that's the case you can even
>>>>> do not have name/rename, but just go ahead and change current Form.
>>>>>
>>>>> I do definitely wanted to see FormItem working as it is now + have
>>>>> stacked Form item where label is on top - you can search - there were such
>>>>> component in flex.
>>>>>
>>>>> I think also that our Form shouldn't contains to many pieces - Right
>>>>> now I have label on the left, container on the right - it's taking too much
>>>>> space - even if it will be super responsive.
>>>>> I do work daily with Vuetify and this is good and non heavy example
>>>>> how Forms should work and eventually look like [1]
>>>>>
>>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
>>>>>
>>>>> Thanks,
>>>>> Piotr
>>>>>
>>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>>>>> napisał(a):
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Jewel Form and FormItem specially, was implemented in a way that I
>>>>>> never was happy. Also others like Piotr had problems doing certain things.
>>>>>> So I was thinking of doing a big refactor, I think it will be
>>>>>> important before we reach 1.0. But before doing this I was thinking first
>>>>>> of leaving the actual Form and FormItem code available for some time as
>>>>>> "deprecated" to be able to take the name for the new components. Another
>>>>>> option could be to make the refactor over the actual control, but that will
>>>>>> mean breaking actual code, so I think that will be a bad idea. Doing this
>>>>>> way, you just need to rename both components in all your apps to the new
>>>>>> name so that seems pretty easy so far.
>>>>>>
>>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>>>>>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>>>>>> same code, and FormItem and FormItemDPCT will have the same code too. If
>>>>>> you have other proposals for the new name let me know.
>>>>>>
>>>>>> The refactor will do a better Form and FormItem responsive, so I
>>>>>> think it is better to layout vertically (label then content controls) by
>>>>>> default and take all available width in mobile screens. I think we'll need
>>>>>> two layouts for the FormItem, one for layout label and content controls,
>>>>>> and other for the content controls itself. Default will be all vertical.
>>>>>>
>>>>>> Then we'll be able to add other jewel layout beads to make all
>>>>>> horizontal or just some parts.
>>>>>> I think that way we'll have all flexibility.
>>>>>>
>>>>>> @Piotr (and others). I think it is the time to put in this thread
>>>>>> anything you think I should consider in this refactor, so if you remember
>>>>>> the main issues please take the time to log in this thread so I can have in
>>>>>> mind.
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>> http://about.me/carlosrovira
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Piotr Zarzycki
>>>>>
>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> http://about.me/carlosrovira
>>>>
>>>>
>>>
>>> --
>>>
>>> Piotr Zarzycki
>>>
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
> --
>
> Piotr Zarzycki
>


-- 

Piotr Zarzycki

Re: Thinking about Jewel Forms refactor

Posted by Piotr Zarzycki <pi...@gmail.com>.
What's more Hugo is using my extension as well - cause he expressed need of
that -  I have send him off the list that one. I'm not the only person who
uses in their app stacked Form.

śr., 9 wrz 2020 o 09:45 Piotr Zarzycki <pi...@gmail.com>
napisał(a):

> Yes I have more extension of current Form - I didn't commit this to Royale
> in the results of our discussion a while ago. I have made significant
> changes to FormView to improve it and created stacked form layout.
>
> Anyway go ahead and do whatever you think - let me know and I will apply
> your changes to our app using your branch.
>
> śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
>> Hi Piotr,
>>
>> don't understand all you said. You mean you have a stacked form layout
>> now? that maybe is because you created your own extensions?
>>
>> I think the objective here should be to work on a final implementation
>> that makes the Form/FormItem components behave in the most general way
>> while it's easy to do other kinds of layouts. I'm afraid of people having
>> problems as they start using it because the actual Form set is very
>> "particular". So it's not a problem for me to work on that to make it as
>> more "general" as possible. As I end changes you can I'll try to give a way
>> to make it work as before too, I hopefully think it could be possible.
>> Other things could be if people have some personal extensions or changes,
>> since that could make it more difficult for them to change to the new one,
>> but I expect the new Form will have a better look and feel.
>>
>>
>> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
>> piotrzarzycki21@gmail.com>) escribió:
>>
>>> Carlos,
>>>
>>> If you won't do  stacked in the first shot - I won't use it - We have a
>>> lot of stacked stuff in our app. Without it it will just fail and apart of
>>> changing code I will have to change more.. Sure if I have time I will help,
>>> but I cannot promise I will get time for this from company.
>>>
>>> Having stuff in branch prevents me from changing my app till
>>> everything work fully. - I can test stuf separately - instead deal with
>>> some changes earlier in app and hold myself from using newest nightly.
>>> Branch is the way to go in my opinion.
>>>
>>> Thanks,
>>> Piotr
>>>
>>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
>>> napisał(a):
>>>
>>>> Hi Piotr,
>>>>
>>>> (sending this to both user and dev since it affects to current users
>>>> and we're discussing how to work on it)
>>>>
>>>> I prefer your approach to work in a branch over the current Form code,
>>>> when finished it will require as well do some changes in final user code so
>>>> in the end changes should be done one way or the other. it's ok for me.
>>>> I'll be waiting a bit for any other input about this, and if nobody
>>>> opposite will go that route.
>>>>
>>>> I think the default will become "stacked" since I think is the most
>>>> typical/used, then we can have other flavours like the current layout
>>>> (horizontal) and even the one show in vuetify or material where labels
>>>> start as prompt and then shrink to the top of the control (for textinput),
>>>> but I guess this could be a bead at form level that. Probably for people
>>>> happy with the current layout they could continue using it overriding the
>>>> set of default beads in his app's css (hopefully).
>>>>
>>>>
>>>>
>>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
>>>> piotrzarzycki21@gmail.com>) escribió:
>>>>
>>>>> Hi Carlos,
>>>>>
>>>>> If you think about changing name of the current component to FormDPCT
>>>>> and write new one with old name - I prefer if you do just the opposite.
>>>>> Name your new component in some way - once you will be ready - we will test
>>>>> it and decide how it's working.
>>>>>
>>>>> IMO it should be done on the branch - if that's the case you can even
>>>>> do not have name/rename, but just go ahead and change current Form.
>>>>>
>>>>> I do definitely wanted to see FormItem working as it is now + have
>>>>> stacked Form item where label is on top - you can search - there were such
>>>>> component in flex.
>>>>>
>>>>> I think also that our Form shouldn't contains to many pieces - Right
>>>>> now I have label on the left, container on the right - it's taking too much
>>>>> space - even if it will be super responsive.
>>>>> I do work daily with Vuetify and this is good and non heavy example
>>>>> how Forms should work and eventually look like [1]
>>>>>
>>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
>>>>>
>>>>> Thanks,
>>>>> Piotr
>>>>>
>>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>>>>> napisał(a):
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Jewel Form and FormItem specially, was implemented in a way that I
>>>>>> never was happy. Also others like Piotr had problems doing certain things.
>>>>>> So I was thinking of doing a big refactor, I think it will be
>>>>>> important before we reach 1.0. But before doing this I was thinking first
>>>>>> of leaving the actual Form and FormItem code available for some time as
>>>>>> "deprecated" to be able to take the name for the new components. Another
>>>>>> option could be to make the refactor over the actual control, but that will
>>>>>> mean breaking actual code, so I think that will be a bad idea. Doing this
>>>>>> way, you just need to rename both components in all your apps to the new
>>>>>> name so that seems pretty easy so far.
>>>>>>
>>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>>>>>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>>>>>> same code, and FormItem and FormItemDPCT will have the same code too. If
>>>>>> you have other proposals for the new name let me know.
>>>>>>
>>>>>> The refactor will do a better Form and FormItem responsive, so I
>>>>>> think it is better to layout vertically (label then content controls) by
>>>>>> default and take all available width in mobile screens. I think we'll need
>>>>>> two layouts for the FormItem, one for layout label and content controls,
>>>>>> and other for the content controls itself. Default will be all vertical.
>>>>>>
>>>>>> Then we'll be able to add other jewel layout beads to make all
>>>>>> horizontal or just some parts.
>>>>>> I think that way we'll have all flexibility.
>>>>>>
>>>>>> @Piotr (and others). I think it is the time to put in this thread
>>>>>> anything you think I should consider in this refactor, so if you remember
>>>>>> the main issues please take the time to log in this thread so I can have in
>>>>>> mind.
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>> http://about.me/carlosrovira
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Piotr Zarzycki
>>>>>
>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> http://about.me/carlosrovira
>>>>
>>>>
>>>
>>> --
>>>
>>> Piotr Zarzycki
>>>
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
> --
>
> Piotr Zarzycki
>


-- 

Piotr Zarzycki

Re: Thinking about Jewel Forms refactor

Posted by Piotr Zarzycki <pi...@gmail.com>.
Yes I have more extension of current Form - I didn't commit this to Royale
in the results of our discussion a while ago. I have made significant
changes to FormView to improve it and created stacked form layout.

Anyway go ahead and do whatever you think - let me know and I will apply
your changes to our app using your branch.

śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org> napisał(a):

> Hi Piotr,
>
> don't understand all you said. You mean you have a stacked form layout
> now? that maybe is because you created your own extensions?
>
> I think the objective here should be to work on a final implementation
> that makes the Form/FormItem components behave in the most general way
> while it's easy to do other kinds of layouts. I'm afraid of people having
> problems as they start using it because the actual Form set is very
> "particular". So it's not a problem for me to work on that to make it as
> more "general" as possible. As I end changes you can I'll try to give a way
> to make it work as before too, I hopefully think it could be possible.
> Other things could be if people have some personal extensions or changes,
> since that could make it more difficult for them to change to the new one,
> but I expect the new Form will have a better look and feel.
>
>
> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
>> Carlos,
>>
>> If you won't do  stacked in the first shot - I won't use it - We have a
>> lot of stacked stuff in our app. Without it it will just fail and apart of
>> changing code I will have to change more.. Sure if I have time I will help,
>> but I cannot promise I will get time for this from company.
>>
>> Having stuff in branch prevents me from changing my app till
>> everything work fully. - I can test stuf separately - instead deal with
>> some changes earlier in app and hold myself from using newest nightly.
>> Branch is the way to go in my opinion.
>>
>> Thanks,
>> Piotr
>>
>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
>> napisał(a):
>>
>>> Hi Piotr,
>>>
>>> (sending this to both user and dev since it affects to current users and
>>> we're discussing how to work on it)
>>>
>>> I prefer your approach to work in a branch over the current Form code,
>>> when finished it will require as well do some changes in final user code so
>>> in the end changes should be done one way or the other. it's ok for me.
>>> I'll be waiting a bit for any other input about this, and if nobody
>>> opposite will go that route.
>>>
>>> I think the default will become "stacked" since I think is the most
>>> typical/used, then we can have other flavours like the current layout
>>> (horizontal) and even the one show in vuetify or material where labels
>>> start as prompt and then shrink to the top of the control (for textinput),
>>> but I guess this could be a bead at form level that. Probably for people
>>> happy with the current layout they could continue using it overriding the
>>> set of default beads in his app's css (hopefully).
>>>
>>>
>>>
>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
>>> piotrzarzycki21@gmail.com>) escribió:
>>>
>>>> Hi Carlos,
>>>>
>>>> If you think about changing name of the current component to FormDPCT
>>>> and write new one with old name - I prefer if you do just the opposite.
>>>> Name your new component in some way - once you will be ready - we will test
>>>> it and decide how it's working.
>>>>
>>>> IMO it should be done on the branch - if that's the case you can even
>>>> do not have name/rename, but just go ahead and change current Form.
>>>>
>>>> I do definitely wanted to see FormItem working as it is now + have
>>>> stacked Form item where label is on top - you can search - there were such
>>>> component in flex.
>>>>
>>>> I think also that our Form shouldn't contains to many pieces - Right
>>>> now I have label on the left, container on the right - it's taking too much
>>>> space - even if it will be super responsive.
>>>> I do work daily with Vuetify and this is good and non heavy example how
>>>> Forms should work and eventually look like [1]
>>>>
>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
>>>>
>>>> Thanks,
>>>> Piotr
>>>>
>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>>>> napisał(a):
>>>>
>>>>> Hi all,
>>>>>
>>>>> Jewel Form and FormItem specially, was implemented in a way that I
>>>>> never was happy. Also others like Piotr had problems doing certain things.
>>>>> So I was thinking of doing a big refactor, I think it will be
>>>>> important before we reach 1.0. But before doing this I was thinking first
>>>>> of leaving the actual Form and FormItem code available for some time as
>>>>> "deprecated" to be able to take the name for the new components. Another
>>>>> option could be to make the refactor over the actual control, but that will
>>>>> mean breaking actual code, so I think that will be a bad idea. Doing this
>>>>> way, you just need to rename both components in all your apps to the new
>>>>> name so that seems pretty easy so far.
>>>>>
>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>>>>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>>>>> same code, and FormItem and FormItemDPCT will have the same code too. If
>>>>> you have other proposals for the new name let me know.
>>>>>
>>>>> The refactor will do a better Form and FormItem responsive, so I think
>>>>> it is better to layout vertically (label then content controls) by default
>>>>> and take all available width in mobile screens. I think we'll need two
>>>>> layouts for the FormItem, one for layout label and content controls, and
>>>>> other for the content controls itself. Default will be all vertical.
>>>>>
>>>>> Then we'll be able to add other jewel layout beads to make all
>>>>> horizontal or just some parts.
>>>>> I think that way we'll have all flexibility.
>>>>>
>>>>> @Piotr (and others). I think it is the time to put in this thread
>>>>> anything you think I should consider in this refactor, so if you remember
>>>>> the main issues please take the time to log in this thread so I can have in
>>>>> mind.
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>> http://about.me/carlosrovira
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> Piotr Zarzycki
>>>>
>>>
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>>
>>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>

-- 

Piotr Zarzycki

Re: Thinking about Jewel Forms refactor

Posted by Piotr Zarzycki <pi...@gmail.com>.
Yes I have more extension of current Form - I didn't commit this to Royale
in the results of our discussion a while ago. I have made significant
changes to FormView to improve it and created stacked form layout.

Anyway go ahead and do whatever you think - let me know and I will apply
your changes to our app using your branch.

śr., 9 wrz 2020 o 09:40 Carlos Rovira <ca...@apache.org> napisał(a):

> Hi Piotr,
>
> don't understand all you said. You mean you have a stacked form layout
> now? that maybe is because you created your own extensions?
>
> I think the objective here should be to work on a final implementation
> that makes the Form/FormItem components behave in the most general way
> while it's easy to do other kinds of layouts. I'm afraid of people having
> problems as they start using it because the actual Form set is very
> "particular". So it's not a problem for me to work on that to make it as
> more "general" as possible. As I end changes you can I'll try to give a way
> to make it work as before too, I hopefully think it could be possible.
> Other things could be if people have some personal extensions or changes,
> since that could make it more difficult for them to change to the new one,
> but I expect the new Form will have a better look and feel.
>
>
> El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
>> Carlos,
>>
>> If you won't do  stacked in the first shot - I won't use it - We have a
>> lot of stacked stuff in our app. Without it it will just fail and apart of
>> changing code I will have to change more.. Sure if I have time I will help,
>> but I cannot promise I will get time for this from company.
>>
>> Having stuff in branch prevents me from changing my app till
>> everything work fully. - I can test stuf separately - instead deal with
>> some changes earlier in app and hold myself from using newest nightly.
>> Branch is the way to go in my opinion.
>>
>> Thanks,
>> Piotr
>>
>> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
>> napisał(a):
>>
>>> Hi Piotr,
>>>
>>> (sending this to both user and dev since it affects to current users and
>>> we're discussing how to work on it)
>>>
>>> I prefer your approach to work in a branch over the current Form code,
>>> when finished it will require as well do some changes in final user code so
>>> in the end changes should be done one way or the other. it's ok for me.
>>> I'll be waiting a bit for any other input about this, and if nobody
>>> opposite will go that route.
>>>
>>> I think the default will become "stacked" since I think is the most
>>> typical/used, then we can have other flavours like the current layout
>>> (horizontal) and even the one show in vuetify or material where labels
>>> start as prompt and then shrink to the top of the control (for textinput),
>>> but I guess this could be a bead at form level that. Probably for people
>>> happy with the current layout they could continue using it overriding the
>>> set of default beads in his app's css (hopefully).
>>>
>>>
>>>
>>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
>>> piotrzarzycki21@gmail.com>) escribió:
>>>
>>>> Hi Carlos,
>>>>
>>>> If you think about changing name of the current component to FormDPCT
>>>> and write new one with old name - I prefer if you do just the opposite.
>>>> Name your new component in some way - once you will be ready - we will test
>>>> it and decide how it's working.
>>>>
>>>> IMO it should be done on the branch - if that's the case you can even
>>>> do not have name/rename, but just go ahead and change current Form.
>>>>
>>>> I do definitely wanted to see FormItem working as it is now + have
>>>> stacked Form item where label is on top - you can search - there were such
>>>> component in flex.
>>>>
>>>> I think also that our Form shouldn't contains to many pieces - Right
>>>> now I have label on the left, container on the right - it's taking too much
>>>> space - even if it will be super responsive.
>>>> I do work daily with Vuetify and this is good and non heavy example how
>>>> Forms should work and eventually look like [1]
>>>>
>>>> [1] https://vuetifyjs.com/en/components/forms/#forms
>>>>
>>>> Thanks,
>>>> Piotr
>>>>
>>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>>>> napisał(a):
>>>>
>>>>> Hi all,
>>>>>
>>>>> Jewel Form and FormItem specially, was implemented in a way that I
>>>>> never was happy. Also others like Piotr had problems doing certain things.
>>>>> So I was thinking of doing a big refactor, I think it will be
>>>>> important before we reach 1.0. But before doing this I was thinking first
>>>>> of leaving the actual Form and FormItem code available for some time as
>>>>> "deprecated" to be able to take the name for the new components. Another
>>>>> option could be to make the refactor over the actual control, but that will
>>>>> mean breaking actual code, so I think that will be a bad idea. Doing this
>>>>> way, you just need to rename both components in all your apps to the new
>>>>> name so that seems pretty easy so far.
>>>>>
>>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>>>>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>>>>> same code, and FormItem and FormItemDPCT will have the same code too. If
>>>>> you have other proposals for the new name let me know.
>>>>>
>>>>> The refactor will do a better Form and FormItem responsive, so I think
>>>>> it is better to layout vertically (label then content controls) by default
>>>>> and take all available width in mobile screens. I think we'll need two
>>>>> layouts for the FormItem, one for layout label and content controls, and
>>>>> other for the content controls itself. Default will be all vertical.
>>>>>
>>>>> Then we'll be able to add other jewel layout beads to make all
>>>>> horizontal or just some parts.
>>>>> I think that way we'll have all flexibility.
>>>>>
>>>>> @Piotr (and others). I think it is the time to put in this thread
>>>>> anything you think I should consider in this refactor, so if you remember
>>>>> the main issues please take the time to log in this thread so I can have in
>>>>> mind.
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>> http://about.me/carlosrovira
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> Piotr Zarzycki
>>>>
>>>
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>>
>>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>

-- 

Piotr Zarzycki

Re: Thinking about Jewel Forms refactor

Posted by Carlos Rovira <ca...@apache.org>.
Hi Piotr,

don't understand all you said. You mean you have a stacked form layout now?
that maybe is because you created your own extensions?

I think the objective here should be to work on a final implementation that
makes the Form/FormItem components behave in the most general way while
it's easy to do other kinds of layouts. I'm afraid of people having
problems as they start using it because the actual Form set is very
"particular". So it's not a problem for me to work on that to make it as
more "general" as possible. As I end changes you can I'll try to give a way
to make it work as before too, I hopefully think it could be possible.
Other things could be if people have some personal extensions or changes,
since that could make it more difficult for them to change to the new one,
but I expect the new Form will have a better look and feel.


El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<pi...@gmail.com>)
escribió:

> Carlos,
>
> If you won't do  stacked in the first shot - I won't use it - We have a
> lot of stacked stuff in our app. Without it it will just fail and apart of
> changing code I will have to change more.. Sure if I have time I will help,
> but I cannot promise I will get time for this from company.
>
> Having stuff in branch prevents me from changing my app till
> everything work fully. - I can test stuf separately - instead deal with
> some changes earlier in app and hold myself from using newest nightly.
> Branch is the way to go in my opinion.
>
> Thanks,
> Piotr
>
> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
>> Hi Piotr,
>>
>> (sending this to both user and dev since it affects to current users and
>> we're discussing how to work on it)
>>
>> I prefer your approach to work in a branch over the current Form code,
>> when finished it will require as well do some changes in final user code so
>> in the end changes should be done one way or the other. it's ok for me.
>> I'll be waiting a bit for any other input about this, and if nobody
>> opposite will go that route.
>>
>> I think the default will become "stacked" since I think is the most
>> typical/used, then we can have other flavours like the current layout
>> (horizontal) and even the one show in vuetify or material where labels
>> start as prompt and then shrink to the top of the control (for textinput),
>> but I guess this could be a bead at form level that. Probably for people
>> happy with the current layout they could continue using it overriding the
>> set of default beads in his app's css (hopefully).
>>
>>
>>
>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
>> piotrzarzycki21@gmail.com>) escribió:
>>
>>> Hi Carlos,
>>>
>>> If you think about changing name of the current component to FormDPCT
>>> and write new one with old name - I prefer if you do just the opposite.
>>> Name your new component in some way - once you will be ready - we will test
>>> it and decide how it's working.
>>>
>>> IMO it should be done on the branch - if that's the case you can even do
>>> not have name/rename, but just go ahead and change current Form.
>>>
>>> I do definitely wanted to see FormItem working as it is now + have
>>> stacked Form item where label is on top - you can search - there were such
>>> component in flex.
>>>
>>> I think also that our Form shouldn't contains to many pieces - Right now
>>> I have label on the left, container on the right - it's taking too much
>>> space - even if it will be super responsive.
>>> I do work daily with Vuetify and this is good and non heavy example how
>>> Forms should work and eventually look like [1]
>>>
>>> [1] https://vuetifyjs.com/en/components/forms/#forms
>>>
>>> Thanks,
>>> Piotr
>>>
>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>>> napisał(a):
>>>
>>>> Hi all,
>>>>
>>>> Jewel Form and FormItem specially, was implemented in a way that I
>>>> never was happy. Also others like Piotr had problems doing certain things.
>>>> So I was thinking of doing a big refactor, I think it will be important
>>>> before we reach 1.0. But before doing this I was thinking first of leaving
>>>> the actual Form and FormItem code available for some time as "deprecated"
>>>> to be able to take the name for the new components. Another option could be
>>>> to make the refactor over the actual control, but that will mean breaking
>>>> actual code, so I think that will be a bad idea. Doing this way, you just
>>>> need to rename both components in all your apps to the new name so that
>>>> seems pretty easy so far.
>>>>
>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>>>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>>>> same code, and FormItem and FormItemDPCT will have the same code too. If
>>>> you have other proposals for the new name let me know.
>>>>
>>>> The refactor will do a better Form and FormItem responsive, so I think
>>>> it is better to layout vertically (label then content controls) by default
>>>> and take all available width in mobile screens. I think we'll need two
>>>> layouts for the FormItem, one for layout label and content controls, and
>>>> other for the content controls itself. Default will be all vertical.
>>>>
>>>> Then we'll be able to add other jewel layout beads to make all
>>>> horizontal or just some parts.
>>>> I think that way we'll have all flexibility.
>>>>
>>>> @Piotr (and others). I think it is the time to put in this thread
>>>> anything you think I should consider in this refactor, so if you remember
>>>> the main issues please take the time to log in this thread so I can have in
>>>> mind.
>>>>
>>>> --
>>>> Carlos Rovira
>>>> http://about.me/carlosrovira
>>>>
>>>>
>>>
>>> --
>>>
>>> Piotr Zarzycki
>>>
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
> --
>
> Piotr Zarzycki
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Thinking about Jewel Forms refactor

Posted by Carlos Rovira <ca...@apache.org>.
Hi Piotr,

don't understand all you said. You mean you have a stacked form layout now?
that maybe is because you created your own extensions?

I think the objective here should be to work on a final implementation that
makes the Form/FormItem components behave in the most general way while
it's easy to do other kinds of layouts. I'm afraid of people having
problems as they start using it because the actual Form set is very
"particular". So it's not a problem for me to work on that to make it as
more "general" as possible. As I end changes you can I'll try to give a way
to make it work as before too, I hopefully think it could be possible.
Other things could be if people have some personal extensions or changes,
since that could make it more difficult for them to change to the new one,
but I expect the new Form will have a better look and feel.


El mié., 9 sept. 2020 a las 9:30, Piotr Zarzycki (<pi...@gmail.com>)
escribió:

> Carlos,
>
> If you won't do  stacked in the first shot - I won't use it - We have a
> lot of stacked stuff in our app. Without it it will just fail and apart of
> changing code I will have to change more.. Sure if I have time I will help,
> but I cannot promise I will get time for this from company.
>
> Having stuff in branch prevents me from changing my app till
> everything work fully. - I can test stuf separately - instead deal with
> some changes earlier in app and hold myself from using newest nightly.
> Branch is the way to go in my opinion.
>
> Thanks,
> Piotr
>
> śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
>> Hi Piotr,
>>
>> (sending this to both user and dev since it affects to current users and
>> we're discussing how to work on it)
>>
>> I prefer your approach to work in a branch over the current Form code,
>> when finished it will require as well do some changes in final user code so
>> in the end changes should be done one way or the other. it's ok for me.
>> I'll be waiting a bit for any other input about this, and if nobody
>> opposite will go that route.
>>
>> I think the default will become "stacked" since I think is the most
>> typical/used, then we can have other flavours like the current layout
>> (horizontal) and even the one show in vuetify or material where labels
>> start as prompt and then shrink to the top of the control (for textinput),
>> but I guess this could be a bead at form level that. Probably for people
>> happy with the current layout they could continue using it overriding the
>> set of default beads in his app's css (hopefully).
>>
>>
>>
>> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
>> piotrzarzycki21@gmail.com>) escribió:
>>
>>> Hi Carlos,
>>>
>>> If you think about changing name of the current component to FormDPCT
>>> and write new one with old name - I prefer if you do just the opposite.
>>> Name your new component in some way - once you will be ready - we will test
>>> it and decide how it's working.
>>>
>>> IMO it should be done on the branch - if that's the case you can even do
>>> not have name/rename, but just go ahead and change current Form.
>>>
>>> I do definitely wanted to see FormItem working as it is now + have
>>> stacked Form item where label is on top - you can search - there were such
>>> component in flex.
>>>
>>> I think also that our Form shouldn't contains to many pieces - Right now
>>> I have label on the left, container on the right - it's taking too much
>>> space - even if it will be super responsive.
>>> I do work daily with Vuetify and this is good and non heavy example how
>>> Forms should work and eventually look like [1]
>>>
>>> [1] https://vuetifyjs.com/en/components/forms/#forms
>>>
>>> Thanks,
>>> Piotr
>>>
>>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>>> napisał(a):
>>>
>>>> Hi all,
>>>>
>>>> Jewel Form and FormItem specially, was implemented in a way that I
>>>> never was happy. Also others like Piotr had problems doing certain things.
>>>> So I was thinking of doing a big refactor, I think it will be important
>>>> before we reach 1.0. But before doing this I was thinking first of leaving
>>>> the actual Form and FormItem code available for some time as "deprecated"
>>>> to be able to take the name for the new components. Another option could be
>>>> to make the refactor over the actual control, but that will mean breaking
>>>> actual code, so I think that will be a bad idea. Doing this way, you just
>>>> need to rename both components in all your apps to the new name so that
>>>> seems pretty easy so far.
>>>>
>>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>>>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>>>> same code, and FormItem and FormItemDPCT will have the same code too. If
>>>> you have other proposals for the new name let me know.
>>>>
>>>> The refactor will do a better Form and FormItem responsive, so I think
>>>> it is better to layout vertically (label then content controls) by default
>>>> and take all available width in mobile screens. I think we'll need two
>>>> layouts for the FormItem, one for layout label and content controls, and
>>>> other for the content controls itself. Default will be all vertical.
>>>>
>>>> Then we'll be able to add other jewel layout beads to make all
>>>> horizontal or just some parts.
>>>> I think that way we'll have all flexibility.
>>>>
>>>> @Piotr (and others). I think it is the time to put in this thread
>>>> anything you think I should consider in this refactor, so if you remember
>>>> the main issues please take the time to log in this thread so I can have in
>>>> mind.
>>>>
>>>> --
>>>> Carlos Rovira
>>>> http://about.me/carlosrovira
>>>>
>>>>
>>>
>>> --
>>>
>>> Piotr Zarzycki
>>>
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
> --
>
> Piotr Zarzycki
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Thinking about Jewel Forms refactor

Posted by Piotr Zarzycki <pi...@gmail.com>.
Carlos,

If you won't do  stacked in the first shot - I won't use it - We have a lot
of stacked stuff in our app. Without it it will just fail and apart of
changing code I will have to change more.. Sure if I have time I will help,
but I cannot promise I will get time for this from company.

Having stuff in branch prevents me from changing my app till
everything work fully. - I can test stuf separately - instead deal with
some changes earlier in app and hold myself from using newest nightly.
Branch is the way to go in my opinion.

Thanks,
Piotr

śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org> napisał(a):

> Hi Piotr,
>
> (sending this to both user and dev since it affects to current users and
> we're discussing how to work on it)
>
> I prefer your approach to work in a branch over the current Form code,
> when finished it will require as well do some changes in final user code so
> in the end changes should be done one way or the other. it's ok for me.
> I'll be waiting a bit for any other input about this, and if nobody
> opposite will go that route.
>
> I think the default will become "stacked" since I think is the most
> typical/used, then we can have other flavours like the current layout
> (horizontal) and even the one show in vuetify or material where labels
> start as prompt and then shrink to the top of the control (for textinput),
> but I guess this could be a bead at form level that. Probably for people
> happy with the current layout they could continue using it overriding the
> set of default beads in his app's css (hopefully).
>
>
>
> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
>> Hi Carlos,
>>
>> If you think about changing name of the current component to FormDPCT and
>> write new one with old name - I prefer if you do just the opposite. Name
>> your new component in some way - once you will be ready - we will test it
>> and decide how it's working.
>>
>> IMO it should be done on the branch - if that's the case you can even do
>> not have name/rename, but just go ahead and change current Form.
>>
>> I do definitely wanted to see FormItem working as it is now + have
>> stacked Form item where label is on top - you can search - there were such
>> component in flex.
>>
>> I think also that our Form shouldn't contains to many pieces - Right now
>> I have label on the left, container on the right - it's taking too much
>> space - even if it will be super responsive.
>> I do work daily with Vuetify and this is good and non heavy example how
>> Forms should work and eventually look like [1]
>>
>> [1] https://vuetifyjs.com/en/components/forms/#forms
>>
>> Thanks,
>> Piotr
>>
>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>> napisał(a):
>>
>>> Hi all,
>>>
>>> Jewel Form and FormItem specially, was implemented in a way that I never
>>> was happy. Also others like Piotr had problems doing certain things.
>>> So I was thinking of doing a big refactor, I think it will be important
>>> before we reach 1.0. But before doing this I was thinking first of leaving
>>> the actual Form and FormItem code available for some time as "deprecated"
>>> to be able to take the name for the new components. Another option could be
>>> to make the refactor over the actual control, but that will mean breaking
>>> actual code, so I think that will be a bad idea. Doing this way, you just
>>> need to rename both components in all your apps to the new name so that
>>> seems pretty easy so far.
>>>
>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>>> same code, and FormItem and FormItemDPCT will have the same code too. If
>>> you have other proposals for the new name let me know.
>>>
>>> The refactor will do a better Form and FormItem responsive, so I think
>>> it is better to layout vertically (label then content controls) by default
>>> and take all available width in mobile screens. I think we'll need two
>>> layouts for the FormItem, one for layout label and content controls, and
>>> other for the content controls itself. Default will be all vertical.
>>>
>>> Then we'll be able to add other jewel layout beads to make all
>>> horizontal or just some parts.
>>> I think that way we'll have all flexibility.
>>>
>>> @Piotr (and others). I think it is the time to put in this thread
>>> anything you think I should consider in this refactor, so if you remember
>>> the main issues please take the time to log in this thread so I can have in
>>> mind.
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>>
>>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>

-- 

Piotr Zarzycki

Re: Thinking about Jewel Forms refactor

Posted by Piotr Zarzycki <pi...@gmail.com>.
Carlos,

If you won't do  stacked in the first shot - I won't use it - We have a lot
of stacked stuff in our app. Without it it will just fail and apart of
changing code I will have to change more.. Sure if I have time I will help,
but I cannot promise I will get time for this from company.

Having stuff in branch prevents me from changing my app till
everything work fully. - I can test stuf separately - instead deal with
some changes earlier in app and hold myself from using newest nightly.
Branch is the way to go in my opinion.

Thanks,
Piotr

śr., 9 wrz 2020 o 09:25 Carlos Rovira <ca...@apache.org> napisał(a):

> Hi Piotr,
>
> (sending this to both user and dev since it affects to current users and
> we're discussing how to work on it)
>
> I prefer your approach to work in a branch over the current Form code,
> when finished it will require as well do some changes in final user code so
> in the end changes should be done one way or the other. it's ok for me.
> I'll be waiting a bit for any other input about this, and if nobody
> opposite will go that route.
>
> I think the default will become "stacked" since I think is the most
> typical/used, then we can have other flavours like the current layout
> (horizontal) and even the one show in vuetify or material where labels
> start as prompt and then shrink to the top of the control (for textinput),
> but I guess this could be a bead at form level that. Probably for people
> happy with the current layout they could continue using it overriding the
> set of default beads in his app's css (hopefully).
>
>
>
> El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
>> Hi Carlos,
>>
>> If you think about changing name of the current component to FormDPCT and
>> write new one with old name - I prefer if you do just the opposite. Name
>> your new component in some way - once you will be ready - we will test it
>> and decide how it's working.
>>
>> IMO it should be done on the branch - if that's the case you can even do
>> not have name/rename, but just go ahead and change current Form.
>>
>> I do definitely wanted to see FormItem working as it is now + have
>> stacked Form item where label is on top - you can search - there were such
>> component in flex.
>>
>> I think also that our Form shouldn't contains to many pieces - Right now
>> I have label on the left, container on the right - it's taking too much
>> space - even if it will be super responsive.
>> I do work daily with Vuetify and this is good and non heavy example how
>> Forms should work and eventually look like [1]
>>
>> [1] https://vuetifyjs.com/en/components/forms/#forms
>>
>> Thanks,
>> Piotr
>>
>> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
>> napisał(a):
>>
>>> Hi all,
>>>
>>> Jewel Form and FormItem specially, was implemented in a way that I never
>>> was happy. Also others like Piotr had problems doing certain things.
>>> So I was thinking of doing a big refactor, I think it will be important
>>> before we reach 1.0. But before doing this I was thinking first of leaving
>>> the actual Form and FormItem code available for some time as "deprecated"
>>> to be able to take the name for the new components. Another option could be
>>> to make the refactor over the actual control, but that will mean breaking
>>> actual code, so I think that will be a bad idea. Doing this way, you just
>>> need to rename both components in all your apps to the new name so that
>>> seems pretty easy so far.
>>>
>>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>>> same code, and FormItem and FormItemDPCT will have the same code too. If
>>> you have other proposals for the new name let me know.
>>>
>>> The refactor will do a better Form and FormItem responsive, so I think
>>> it is better to layout vertically (label then content controls) by default
>>> and take all available width in mobile screens. I think we'll need two
>>> layouts for the FormItem, one for layout label and content controls, and
>>> other for the content controls itself. Default will be all vertical.
>>>
>>> Then we'll be able to add other jewel layout beads to make all
>>> horizontal or just some parts.
>>> I think that way we'll have all flexibility.
>>>
>>> @Piotr (and others). I think it is the time to put in this thread
>>> anything you think I should consider in this refactor, so if you remember
>>> the main issues please take the time to log in this thread so I can have in
>>> mind.
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>>
>>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>

-- 

Piotr Zarzycki

Re: Thinking about Jewel Forms refactor

Posted by Carlos Rovira <ca...@apache.org>.
Hi Piotr,

(sending this to both user and dev since it affects to current users and
we're discussing how to work on it)

I prefer your approach to work in a branch over the current Form code, when
finished it will require as well do some changes in final user code so in
the end changes should be done one way or the other. it's ok for me. I'll
be waiting a bit for any other input about this, and if nobody opposite
will go that route.

I think the default will become "stacked" since I think is the most
typical/used, then we can have other flavours like the current layout
(horizontal) and even the one show in vuetify or material where labels
start as prompt and then shrink to the top of the control (for textinput),
but I guess this could be a bead at form level that. Probably for people
happy with the current layout they could continue using it overriding the
set of default beads in his app's css (hopefully).



El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<pi...@gmail.com>)
escribió:

> Hi Carlos,
>
> If you think about changing name of the current component to FormDPCT and
> write new one with old name - I prefer if you do just the opposite. Name
> your new component in some way - once you will be ready - we will test it
> and decide how it's working.
>
> IMO it should be done on the branch - if that's the case you can even do
> not have name/rename, but just go ahead and change current Form.
>
> I do definitely wanted to see FormItem working as it is now + have stacked
> Form item where label is on top - you can search - there were such
> component in flex.
>
> I think also that our Form shouldn't contains to many pieces - Right now I
> have label on the left, container on the right - it's taking too much space
> - even if it will be super responsive.
> I do work daily with Vuetify and this is good and non heavy example how
> Forms should work and eventually look like [1]
>
> [1] https://vuetifyjs.com/en/components/forms/#forms
>
> Thanks,
> Piotr
>
> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
>> Hi all,
>>
>> Jewel Form and FormItem specially, was implemented in a way that I never
>> was happy. Also others like Piotr had problems doing certain things.
>> So I was thinking of doing a big refactor, I think it will be important
>> before we reach 1.0. But before doing this I was thinking first of leaving
>> the actual Form and FormItem code available for some time as "deprecated"
>> to be able to take the name for the new components. Another option could be
>> to make the refactor over the actual control, but that will mean breaking
>> actual code, so I think that will be a bad idea. Doing this way, you just
>> need to rename both components in all your apps to the new name so that
>> seems pretty easy so far.
>>
>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>> same code, and FormItem and FormItemDPCT will have the same code too. If
>> you have other proposals for the new name let me know.
>>
>> The refactor will do a better Form and FormItem responsive, so I think it
>> is better to layout vertically (label then content controls) by default and
>> take all available width in mobile screens. I think we'll need two layouts
>> for the FormItem, one for layout label and content controls, and other for
>> the content controls itself. Default will be all vertical.
>>
>> Then we'll be able to add other jewel layout beads to make all horizontal
>> or just some parts.
>> I think that way we'll have all flexibility.
>>
>> @Piotr (and others). I think it is the time to put in this thread
>> anything you think I should consider in this refactor, so if you remember
>> the main issues please take the time to log in this thread so I can have in
>> mind.
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
> --
>
> Piotr Zarzycki
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Thinking about Jewel Forms refactor

Posted by Carlos Rovira <ca...@apache.org>.
Hi Piotr,

(sending this to both user and dev since it affects to current users and
we're discussing how to work on it)

I prefer your approach to work in a branch over the current Form code, when
finished it will require as well do some changes in final user code so in
the end changes should be done one way or the other. it's ok for me. I'll
be waiting a bit for any other input about this, and if nobody opposite
will go that route.

I think the default will become "stacked" since I think is the most
typical/used, then we can have other flavours like the current layout
(horizontal) and even the one show in vuetify or material where labels
start as prompt and then shrink to the top of the control (for textinput),
but I guess this could be a bead at form level that. Probably for people
happy with the current layout they could continue using it overriding the
set of default beads in his app's css (hopefully).



El mié., 9 sept. 2020 a las 8:34, Piotr Zarzycki (<pi...@gmail.com>)
escribió:

> Hi Carlos,
>
> If you think about changing name of the current component to FormDPCT and
> write new one with old name - I prefer if you do just the opposite. Name
> your new component in some way - once you will be ready - we will test it
> and decide how it's working.
>
> IMO it should be done on the branch - if that's the case you can even do
> not have name/rename, but just go ahead and change current Form.
>
> I do definitely wanted to see FormItem working as it is now + have stacked
> Form item where label is on top - you can search - there were such
> component in flex.
>
> I think also that our Form shouldn't contains to many pieces - Right now I
> have label on the left, container on the right - it's taking too much space
> - even if it will be super responsive.
> I do work daily with Vuetify and this is good and non heavy example how
> Forms should work and eventually look like [1]
>
> [1] https://vuetifyjs.com/en/components/forms/#forms
>
> Thanks,
> Piotr
>
> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
>> Hi all,
>>
>> Jewel Form and FormItem specially, was implemented in a way that I never
>> was happy. Also others like Piotr had problems doing certain things.
>> So I was thinking of doing a big refactor, I think it will be important
>> before we reach 1.0. But before doing this I was thinking first of leaving
>> the actual Form and FormItem code available for some time as "deprecated"
>> to be able to take the name for the new components. Another option could be
>> to make the refactor over the actual control, but that will mean breaking
>> actual code, so I think that will be a bad idea. Doing this way, you just
>> need to rename both components in all your apps to the new name so that
>> seems pretty easy so far.
>>
>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>> same code, and FormItem and FormItemDPCT will have the same code too. If
>> you have other proposals for the new name let me know.
>>
>> The refactor will do a better Form and FormItem responsive, so I think it
>> is better to layout vertically (label then content controls) by default and
>> take all available width in mobile screens. I think we'll need two layouts
>> for the FormItem, one for layout label and content controls, and other for
>> the content controls itself. Default will be all vertical.
>>
>> Then we'll be able to add other jewel layout beads to make all horizontal
>> or just some parts.
>> I think that way we'll have all flexibility.
>>
>> @Piotr (and others). I think it is the time to put in this thread
>> anything you think I should consider in this refactor, so if you remember
>> the main issues please take the time to log in this thread so I can have in
>> mind.
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
> --
>
> Piotr Zarzycki
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Thinking about Jewel Forms refactor

Posted by Piotr Zarzycki <pi...@gmail.com>.
Sorry I should send it to Dev actually.

śr., 9 wrz 2020 o 08:34 Piotr Zarzycki <pi...@gmail.com>
napisał(a):

> Hi Carlos,
>
> If you think about changing name of the current component to FormDPCT and
> write new one with old name - I prefer if you do just the opposite. Name
> your new component in some way - once you will be ready - we will test it
> and decide how it's working.
>
> IMO it should be done on the branch - if that's the case you can even do
> not have name/rename, but just go ahead and change current Form.
>
> I do definitely wanted to see FormItem working as it is now + have stacked
> Form item where label is on top - you can search - there were such
> component in flex.
>
> I think also that our Form shouldn't contains to many pieces - Right now I
> have label on the left, container on the right - it's taking too much space
> - even if it will be super responsive.
> I do work daily with Vuetify and this is good and non heavy example how
> Forms should work and eventually look like [1]
>
> [1] https://vuetifyjs.com/en/components/forms/#forms
>
> Thanks,
> Piotr
>
> wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
>> Hi all,
>>
>> Jewel Form and FormItem specially, was implemented in a way that I never
>> was happy. Also others like Piotr had problems doing certain things.
>> So I was thinking of doing a big refactor, I think it will be important
>> before we reach 1.0. But before doing this I was thinking first of leaving
>> the actual Form and FormItem code available for some time as "deprecated"
>> to be able to take the name for the new components. Another option could be
>> to make the refactor over the actual control, but that will mean breaking
>> actual code, so I think that will be a bad idea. Doing this way, you just
>> need to rename both components in all your apps to the new name so that
>> seems pretty easy so far.
>>
>> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
>> "Deprecated"). That means that initially, Form and FormDPCT will have the
>> same code, and FormItem and FormItemDPCT will have the same code too. If
>> you have other proposals for the new name let me know.
>>
>> The refactor will do a better Form and FormItem responsive, so I think it
>> is better to layout vertically (label then content controls) by default and
>> take all available width in mobile screens. I think we'll need two layouts
>> for the FormItem, one for layout label and content controls, and other for
>> the content controls itself. Default will be all vertical.
>>
>> Then we'll be able to add other jewel layout beads to make all horizontal
>> or just some parts.
>> I think that way we'll have all flexibility.
>>
>> @Piotr (and others). I think it is the time to put in this thread
>> anything you think I should consider in this refactor, so if you remember
>> the main issues please take the time to log in this thread so I can have in
>> mind.
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
> --
>
> Piotr Zarzycki
>


-- 

Piotr Zarzycki

Re: Thinking about Jewel Forms refactor

Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Carlos,

If you think about changing name of the current component to FormDPCT and
write new one with old name - I prefer if you do just the opposite. Name
your new component in some way - once you will be ready - we will test it
and decide how it's working.

IMO it should be done on the branch - if that's the case you can even do
not have name/rename, but just go ahead and change current Form.

I do definitely wanted to see FormItem working as it is now + have stacked
Form item where label is on top - you can search - there were such
component in flex.

I think also that our Form shouldn't contains to many pieces - Right now I
have label on the left, container on the right - it's taking too much space
- even if it will be super responsive.
I do work daily with Vuetify and this is good and non heavy example how
Forms should work and eventually look like [1]

[1] https://vuetifyjs.com/en/components/forms/#forms

Thanks,
Piotr

wt., 8 wrz 2020 o 22:47 Carlos Rovira <ca...@apache.org> napisał(a):

> Hi all,
>
> Jewel Form and FormItem specially, was implemented in a way that I never
> was happy. Also others like Piotr had problems doing certain things.
> So I was thinking of doing a big refactor, I think it will be important
> before we reach 1.0. But before doing this I was thinking first of leaving
> the actual Form and FormItem code available for some time as "deprecated"
> to be able to take the name for the new components. Another option could be
> to make the refactor over the actual control, but that will mean breaking
> actual code, so I think that will be a bad idea. Doing this way, you just
> need to rename both components in all your apps to the new name so that
> seems pretty easy so far.
>
> So the name could be "FormDPCT" and "FormItemDPCT" (DPCT for
> "Deprecated"). That means that initially, Form and FormDPCT will have the
> same code, and FormItem and FormItemDPCT will have the same code too. If
> you have other proposals for the new name let me know.
>
> The refactor will do a better Form and FormItem responsive, so I think it
> is better to layout vertically (label then content controls) by default and
> take all available width in mobile screens. I think we'll need two layouts
> for the FormItem, one for layout label and content controls, and other for
> the content controls itself. Default will be all vertical.
>
> Then we'll be able to add other jewel layout beads to make all horizontal
> or just some parts.
> I think that way we'll have all flexibility.
>
> @Piotr (and others). I think it is the time to put in this thread anything
> you think I should consider in this refactor, so if you remember the main
> issues please take the time to log in this thread so I can have in mind.
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>

-- 

Piotr Zarzycki