Re: HTML

[Hugo Ferreira]

Thank you all very much for this valuable info.
It will save me counteless hours !
One day (after I finish to rewrite my Flex to Royale project and when I
have spare time and when I learn more about Royale) I will write a book (a
small book) about Apache Royale :)
I don't care if it don't have a single sale (the world have to much books
of the other languages).
Here on my country it counts for the "Curriculum Vitae" and it's one of my
missing pieces (I have patents, etc ... but not yet a techincal book).

Josh Tynjala  escreveu no dia terça, 18/10/2022
à(s) 22:40:

> To build a single project, you can run ant from the project directory:
>
> cd frameworks/projects/Jewel
> ant
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Tue, Oct 18, 2022 at 1:59 PM Hugo Ferreira 
> wrote:
>
> > Fixed, tested and commit done :)
> >
> > Usually I fix using CodEditor (a kind of Notepad++ for macOS) and then
> "ant
> > clean" and then "ant all".
> > It takes more then 30 minutes on my machine !
> > For things more complex I test integrated on my project using VS Code and
> > then I put the code in the SDK, compile and test.
> >
> > For this particular use case, how could I acelerate my workflow ?
> >
> >
> >
> > Harbs  escreveu no dia terça, 18/10/2022 à(s)
> > 21:53:
> >
> > > FYI, it’s not necessary to compile the whole SDK unless your current
> > build
> > > is old. You can compile a single SWC at a time.
> > >
> > > > On Oct 18, 2022, at 11:51 PM, Hugo Ferreira 
> > > wrote:
> > > >
> > > > Yes, it's exactly what I'm doing right now.
> > > > Compiling the SDK on my machine takes the time to dinner and even so,
> > > > probably it's not finished yet !
> > > > I hope next year, I update my MacBook :)
> > > >
> > > > Harbs  escreveu no dia terça, 18/10/2022 à(s)
> > > 21:38:
> > > >
> > > >> Let’s see what others think, but in the meantime there’s no reason
> to
> > > not
> > > >> fix the bug. There are other html setters which already set
> innerHTML.
> > > >>
> > > >> Harbs
> > > >>
> > > >>> On Oct 18, 2022, at 11:29 PM, Hugo Ferreira <
> hferreira...@gmail.com>
> > > >> wrote:
> > > >>>
> > > >>> Yes, I saw that helper (I searched for it name) :)
> > > >>> Yes, it's exactly what I mean: put this in one of the limites of
> the
> > > >>> workflow and never in the middle.
> > > >>> That's my opinion.
> > > >>>
> > > >>>
> > > >>>
> > > >>> Harbs  escreveu no dia terça, 18/10/2022
> à(s)
> > > >> 08:06:
> > > >>>
> > >  There’s a sanitizeHTML helper function that’s relatively new.
> > > 
> > >  I don’t have a strong opinion on whether it should be sanitized by
> > > >> default
> > >  or that should be the application developer’s responsibility.
> > > 
> > >  As far as PAYG is concerned, it’s better to put the responsibility
> > on
> > > >> the
> > >  app developer.
> > > 
> > >  As far as security is concerned, it would be better to sanitize in
> > the
> > >  framework.
> > > 
> > >  I personally would give precedence to PAYG because the threat of a
> > XSS
> > >  attack using innerHTML is a bit of a stretch in Royale.
> > > 
> > >  We should come up with a policy, document it, and stick to it
> across
> > > the
> > >  framework.
> > > 
> > >  If we do sanitize in the components, it should probably happen in
> > the
> > >  model setter.
> > > 
> > >  What do others think?
> > > 
> > > > On Oct 18, 2022, at 2:32 AM, Hugo Ferreira <
> hferreira...@gmail.com
> > >
> > >  wrote:
> > > >
> > > > Thank you very much.
> > > > I see the bug.
> > > > I hope that the Label (html property) that FormHeading that
> depends
> > > on,
> > > > doesn't have the same issue :)
> > > >
> > > > About the sanitize:
> > > > Should this be really a reponsibility of FormHeadingView !?
> > > > Shouldn't the responsibility on one of the edges (the limit of
> html
> > > > property core or on the end application) ?
> > > > In the middle, we could ending "sanitizing" too much just to be
> > > ensure.
> > > >
> > > >
> > > >
> > > > Harbs  escreveu no dia segunda,
> 17/10/2022
> > > à(s)
> > > > 19:25:
> > > >
> > > >> I assume this is Jewel. I don’t use Jewel, but I just looked at
> > > >> FormHeadingView and textChangeHandler is used for both
> textChange
> > > and
> > > >> htmlChange. In both cases it sets the text rather than html in
> the
> > > >> htmlChange case. That seems to be broken.
> > > >>
> > > >> If you fix this, make sure the html is sanitized when applied.
> > > >>
> > > >> Harbs
> > > >>
> > > >>> On Oct 16, 2022, at 5:17 PM, Hugo Ferreira <
> > hferreira...@gmail.com
> > > >
> > > >> wrote:
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> I'm using FormHeading when I have a lot of fields and want to
> > > create
> > > >> a
> > > >>> vertical separation (group of data).
> > > >>> It's OK, h

Re: HTML

[Josh Tynjala]

To build a single project, you can run ant from the project directory:

cd frameworks/projects/Jewel
ant

--
Josh Tynjala
Bowler Hat LLC 


On Tue, Oct 18, 2022 at 1:59 PM Hugo Ferreira 
wrote:

> Fixed, tested and commit done :)
>
> Usually I fix using CodEditor (a kind of Notepad++ for macOS) and then "ant
> clean" and then "ant all".
> It takes more then 30 minutes on my machine !
> For things more complex I test integrated on my project using VS Code and
> then I put the code in the SDK, compile and test.
>
> For this particular use case, how could I acelerate my workflow ?
>
>
>
> Harbs  escreveu no dia terça, 18/10/2022 à(s)
> 21:53:
>
> > FYI, it’s not necessary to compile the whole SDK unless your current
> build
> > is old. You can compile a single SWC at a time.
> >
> > > On Oct 18, 2022, at 11:51 PM, Hugo Ferreira 
> > wrote:
> > >
> > > Yes, it's exactly what I'm doing right now.
> > > Compiling the SDK on my machine takes the time to dinner and even so,
> > > probably it's not finished yet !
> > > I hope next year, I update my MacBook :)
> > >
> > > Harbs  escreveu no dia terça, 18/10/2022 à(s)
> > 21:38:
> > >
> > >> Let’s see what others think, but in the meantime there’s no reason to
> > not
> > >> fix the bug. There are other html setters which already set innerHTML.
> > >>
> > >> Harbs
> > >>
> > >>> On Oct 18, 2022, at 11:29 PM, Hugo Ferreira 
> > >> wrote:
> > >>>
> > >>> Yes, I saw that helper (I searched for it name) :)
> > >>> Yes, it's exactly what I mean: put this in one of the limites of the
> > >>> workflow and never in the middle.
> > >>> That's my opinion.
> > >>>
> > >>>
> > >>>
> > >>> Harbs  escreveu no dia terça, 18/10/2022 à(s)
> > >> 08:06:
> > >>>
> >  There’s a sanitizeHTML helper function that’s relatively new.
> > 
> >  I don’t have a strong opinion on whether it should be sanitized by
> > >> default
> >  or that should be the application developer’s responsibility.
> > 
> >  As far as PAYG is concerned, it’s better to put the responsibility
> on
> > >> the
> >  app developer.
> > 
> >  As far as security is concerned, it would be better to sanitize in
> the
> >  framework.
> > 
> >  I personally would give precedence to PAYG because the threat of a
> XSS
> >  attack using innerHTML is a bit of a stretch in Royale.
> > 
> >  We should come up with a policy, document it, and stick to it across
> > the
> >  framework.
> > 
> >  If we do sanitize in the components, it should probably happen in
> the
> >  model setter.
> > 
> >  What do others think?
> > 
> > > On Oct 18, 2022, at 2:32 AM, Hugo Ferreira  >
> >  wrote:
> > >
> > > Thank you very much.
> > > I see the bug.
> > > I hope that the Label (html property) that FormHeading that depends
> > on,
> > > doesn't have the same issue :)
> > >
> > > About the sanitize:
> > > Should this be really a reponsibility of FormHeadingView !?
> > > Shouldn't the responsibility on one of the edges (the limit of html
> > > property core or on the end application) ?
> > > In the middle, we could ending "sanitizing" too much just to be
> > ensure.
> > >
> > >
> > >
> > > Harbs  escreveu no dia segunda, 17/10/2022
> > à(s)
> > > 19:25:
> > >
> > >> I assume this is Jewel. I don’t use Jewel, but I just looked at
> > >> FormHeadingView and textChangeHandler is used for both textChange
> > and
> > >> htmlChange. In both cases it sets the text rather than html in the
> > >> htmlChange case. That seems to be broken.
> > >>
> > >> If you fix this, make sure the html is sanitized when applied.
> > >>
> > >> Harbs
> > >>
> > >>> On Oct 16, 2022, at 5:17 PM, Hugo Ferreira <
> hferreira...@gmail.com
> > >
> > >> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> I'm using FormHeading when I have a lot of fields and want to
> > create
> > >> a
> > >>> vertical separation (group of data).
> > >>> It's OK, however I needed now to use in the FormHeading texto
> some
> > >> HTML
> > >>> (basic stuff like strong and br), however the property "text" of
> > >>> FormHeading it's for simple real strings and not HTML.
> > >>> I saw the html property, however this property does nothing.
> > >>> It's something that it's not already implemented in the core or
> I'm
> > >> missing
> > >>> something ?
> > >>>
> > >>> I saw tht I can workaround, using a pure html:Div with innerHTML
> > but
> > >> I
> > >> have
> > >>> read in the past that I should avoid it.
> > >>
> > >>
> > 
> > 
> > >>
> > >>
> >
> >
>

Re: HTML

[Harbs]

ant all is only needed if you need to recompile the compiler.

ant on the royale-asjs folder will rebuild all the framework swcs and run all 
tests.

If you are making changes to just a single swc (i.e. Jewel) you can run ant on 
just Jewel. A single swc should compile in a matter of seconds even on slower 
machines.

I have VS Code projects for the whole royale-asjs folder as well as each of the 
swc projects (i.e. Core, Basic, Network, XML etc.) As I’m working, I run ant on 
the specific swc I’m working on. For most swcs it takes a few seconds.

HTH,
Harbs

> On Oct 19, 2022, at 12:01 AM, Hugo Ferreira  wrote:
> 
> Fixed, tested and commit done :)
> 
> Usually I fix using CodEditor (a kind of Notepad++ for macOS) and then "ant
> clean" and then "ant all".
> It takes more then 30 minutes on my machine !
> For things more complex I test integrated on my project using VS Code and
> then I put the code in the SDK, compile and test.
> 
> For this particular use case, how could I acelerate my workflow ?
> 
> 
> 
> Harbs  escreveu no dia terça, 18/10/2022 à(s) 21:53:
> 
>> FYI, it’s not necessary to compile the whole SDK unless your current build
>> is old. You can compile a single SWC at a time.
>> 
>>> On Oct 18, 2022, at 11:51 PM, Hugo Ferreira 
>> wrote:
>>> 
>>> Yes, it's exactly what I'm doing right now.
>>> Compiling the SDK on my machine takes the time to dinner and even so,
>>> probably it's not finished yet !
>>> I hope next year, I update my MacBook :)
>>> 
>>> Harbs  escreveu no dia terça, 18/10/2022 à(s)
>> 21:38:
>>> 
 Let’s see what others think, but in the meantime there’s no reason to
>> not
 fix the bug. There are other html setters which already set innerHTML.
 
 Harbs
 
> On Oct 18, 2022, at 11:29 PM, Hugo Ferreira 
 wrote:
> 
> Yes, I saw that helper (I searched for it name) :)
> Yes, it's exactly what I mean: put this in one of the limites of the
> workflow and never in the middle.
> That's my opinion.
> 
> 
> 
> Harbs  escreveu no dia terça, 18/10/2022 à(s)
 08:06:
> 
>> There’s a sanitizeHTML helper function that’s relatively new.
>> 
>> I don’t have a strong opinion on whether it should be sanitized by
 default
>> or that should be the application developer’s responsibility.
>> 
>> As far as PAYG is concerned, it’s better to put the responsibility on
 the
>> app developer.
>> 
>> As far as security is concerned, it would be better to sanitize in the
>> framework.
>> 
>> I personally would give precedence to PAYG because the threat of a XSS
>> attack using innerHTML is a bit of a stretch in Royale.
>> 
>> We should come up with a policy, document it, and stick to it across
>> the
>> framework.
>> 
>> If we do sanitize in the components, it should probably happen in the
>> model setter.
>> 
>> What do others think?
>> 
>>> On Oct 18, 2022, at 2:32 AM, Hugo Ferreira 
>> wrote:
>>> 
>>> Thank you very much.
>>> I see the bug.
>>> I hope that the Label (html property) that FormHeading that depends
>> on,
>>> doesn't have the same issue :)
>>> 
>>> About the sanitize:
>>> Should this be really a reponsibility of FormHeadingView !?
>>> Shouldn't the responsibility on one of the edges (the limit of html
>>> property core or on the end application) ?
>>> In the middle, we could ending "sanitizing" too much just to be
>> ensure.
>>> 
>>> 
>>> 
>>> Harbs  escreveu no dia segunda, 17/10/2022
>> à(s)
>>> 19:25:
>>> 
 I assume this is Jewel. I don’t use Jewel, but I just looked at
 FormHeadingView and textChangeHandler is used for both textChange
>> and
 htmlChange. In both cases it sets the text rather than html in the
 htmlChange case. That seems to be broken.
 
 If you fix this, make sure the html is sanitized when applied.
 
 Harbs
 
> On Oct 16, 2022, at 5:17 PM, Hugo Ferreira >> 
 wrote:
> 
> Hi,
> 
> I'm using FormHeading when I have a lot of fields and want to
>> create
 a
> vertical separation (group of data).
> It's OK, however I needed now to use in the FormHeading texto some
 HTML
> (basic stuff like strong and br), however the property "text" of
> FormHeading it's for simple real strings and not HTML.
> I saw the html property, however this property does nothing.
> It's something that it's not already implemented in the core or I'm
 missing
> something ?
> 
> I saw tht I can workaround, using a pure html:Div with innerHTML
>> but
 I
 have
> read in the past that I should avoid it.
 
 
>> 
>> 
 
 
>> 
>> 

Re: HTML

[Hugo Ferreira]

Fixed, tested and commit done :)

Usually I fix using CodEditor (a kind of Notepad++ for macOS) and then "ant
clean" and then "ant all".
It takes more then 30 minutes on my machine !
For things more complex I test integrated on my project using VS Code and
then I put the code in the SDK, compile and test.

For this particular use case, how could I acelerate my workflow ?



Harbs  escreveu no dia terça, 18/10/2022 à(s) 21:53:

> FYI, it’s not necessary to compile the whole SDK unless your current build
> is old. You can compile a single SWC at a time.
>
> > On Oct 18, 2022, at 11:51 PM, Hugo Ferreira 
> wrote:
> >
> > Yes, it's exactly what I'm doing right now.
> > Compiling the SDK on my machine takes the time to dinner and even so,
> > probably it's not finished yet !
> > I hope next year, I update my MacBook :)
> >
> > Harbs  escreveu no dia terça, 18/10/2022 à(s)
> 21:38:
> >
> >> Let’s see what others think, but in the meantime there’s no reason to
> not
> >> fix the bug. There are other html setters which already set innerHTML.
> >>
> >> Harbs
> >>
> >>> On Oct 18, 2022, at 11:29 PM, Hugo Ferreira 
> >> wrote:
> >>>
> >>> Yes, I saw that helper (I searched for it name) :)
> >>> Yes, it's exactly what I mean: put this in one of the limites of the
> >>> workflow and never in the middle.
> >>> That's my opinion.
> >>>
> >>>
> >>>
> >>> Harbs  escreveu no dia terça, 18/10/2022 à(s)
> >> 08:06:
> >>>
>  There’s a sanitizeHTML helper function that’s relatively new.
> 
>  I don’t have a strong opinion on whether it should be sanitized by
> >> default
>  or that should be the application developer’s responsibility.
> 
>  As far as PAYG is concerned, it’s better to put the responsibility on
> >> the
>  app developer.
> 
>  As far as security is concerned, it would be better to sanitize in the
>  framework.
> 
>  I personally would give precedence to PAYG because the threat of a XSS
>  attack using innerHTML is a bit of a stretch in Royale.
> 
>  We should come up with a policy, document it, and stick to it across
> the
>  framework.
> 
>  If we do sanitize in the components, it should probably happen in the
>  model setter.
> 
>  What do others think?
> 
> > On Oct 18, 2022, at 2:32 AM, Hugo Ferreira 
>  wrote:
> >
> > Thank you very much.
> > I see the bug.
> > I hope that the Label (html property) that FormHeading that depends
> on,
> > doesn't have the same issue :)
> >
> > About the sanitize:
> > Should this be really a reponsibility of FormHeadingView !?
> > Shouldn't the responsibility on one of the edges (the limit of html
> > property core or on the end application) ?
> > In the middle, we could ending "sanitizing" too much just to be
> ensure.
> >
> >
> >
> > Harbs  escreveu no dia segunda, 17/10/2022
> à(s)
> > 19:25:
> >
> >> I assume this is Jewel. I don’t use Jewel, but I just looked at
> >> FormHeadingView and textChangeHandler is used for both textChange
> and
> >> htmlChange. In both cases it sets the text rather than html in the
> >> htmlChange case. That seems to be broken.
> >>
> >> If you fix this, make sure the html is sanitized when applied.
> >>
> >> Harbs
> >>
> >>> On Oct 16, 2022, at 5:17 PM, Hugo Ferreira  >
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm using FormHeading when I have a lot of fields and want to
> create
> >> a
> >>> vertical separation (group of data).
> >>> It's OK, however I needed now to use in the FormHeading texto some
> >> HTML
> >>> (basic stuff like strong and br), however the property "text" of
> >>> FormHeading it's for simple real strings and not HTML.
> >>> I saw the html property, however this property does nothing.
> >>> It's something that it's not already implemented in the core or I'm
> >> missing
> >>> something ?
> >>>
> >>> I saw tht I can workaround, using a pure html:Div with innerHTML
> but
> >> I
> >> have
> >>> read in the past that I should avoid it.
> >>
> >>
> 
> 
> >>
> >>
>
>

Re: HTML

[Harbs]

FYI, it’s not necessary to compile the whole SDK unless your current build is 
old. You can compile a single SWC at a time.

> On Oct 18, 2022, at 11:51 PM, Hugo Ferreira  wrote:
> 
> Yes, it's exactly what I'm doing right now.
> Compiling the SDK on my machine takes the time to dinner and even so,
> probably it's not finished yet !
> I hope next year, I update my MacBook :)
> 
> Harbs  escreveu no dia terça, 18/10/2022 à(s) 21:38:
> 
>> Let’s see what others think, but in the meantime there’s no reason to not
>> fix the bug. There are other html setters which already set innerHTML.
>> 
>> Harbs
>> 
>>> On Oct 18, 2022, at 11:29 PM, Hugo Ferreira 
>> wrote:
>>> 
>>> Yes, I saw that helper (I searched for it name) :)
>>> Yes, it's exactly what I mean: put this in one of the limites of the
>>> workflow and never in the middle.
>>> That's my opinion.
>>> 
>>> 
>>> 
>>> Harbs  escreveu no dia terça, 18/10/2022 à(s)
>> 08:06:
>>> 
 There’s a sanitizeHTML helper function that’s relatively new.
 
 I don’t have a strong opinion on whether it should be sanitized by
>> default
 or that should be the application developer’s responsibility.
 
 As far as PAYG is concerned, it’s better to put the responsibility on
>> the
 app developer.
 
 As far as security is concerned, it would be better to sanitize in the
 framework.
 
 I personally would give precedence to PAYG because the threat of a XSS
 attack using innerHTML is a bit of a stretch in Royale.
 
 We should come up with a policy, document it, and stick to it across the
 framework.
 
 If we do sanitize in the components, it should probably happen in the
 model setter.
 
 What do others think?
 
> On Oct 18, 2022, at 2:32 AM, Hugo Ferreira 
 wrote:
> 
> Thank you very much.
> I see the bug.
> I hope that the Label (html property) that FormHeading that depends on,
> doesn't have the same issue :)
> 
> About the sanitize:
> Should this be really a reponsibility of FormHeadingView !?
> Shouldn't the responsibility on one of the edges (the limit of html
> property core or on the end application) ?
> In the middle, we could ending "sanitizing" too much just to be ensure.
> 
> 
> 
> Harbs  escreveu no dia segunda, 17/10/2022 à(s)
> 19:25:
> 
>> I assume this is Jewel. I don’t use Jewel, but I just looked at
>> FormHeadingView and textChangeHandler is used for both textChange and
>> htmlChange. In both cases it sets the text rather than html in the
>> htmlChange case. That seems to be broken.
>> 
>> If you fix this, make sure the html is sanitized when applied.
>> 
>> Harbs
>> 
>>> On Oct 16, 2022, at 5:17 PM, Hugo Ferreira 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> I'm using FormHeading when I have a lot of fields and want to create
>> a
>>> vertical separation (group of data).
>>> It's OK, however I needed now to use in the FormHeading texto some
>> HTML
>>> (basic stuff like strong and br), however the property "text" of
>>> FormHeading it's for simple real strings and not HTML.
>>> I saw the html property, however this property does nothing.
>>> It's something that it's not already implemented in the core or I'm
>> missing
>>> something ?
>>> 
>>> I saw tht I can workaround, using a pure html:Div with innerHTML but
>> I
>> have
>>> read in the past that I should avoid it.
>> 
>> 
 
 
>> 
>> 

Re: HTML

[Hugo Ferreira]

Yes, it's exactly what I'm doing right now.
Compiling the SDK on my machine takes the time to dinner and even so,
probably it's not finished yet !
I hope next year, I update my MacBook :)

Harbs  escreveu no dia terça, 18/10/2022 à(s) 21:38:

> Let’s see what others think, but in the meantime there’s no reason to not
> fix the bug. There are other html setters which already set innerHTML.
>
> Harbs
>
> > On Oct 18, 2022, at 11:29 PM, Hugo Ferreira 
> wrote:
> >
> > Yes, I saw that helper (I searched for it name) :)
> > Yes, it's exactly what I mean: put this in one of the limites of the
> > workflow and never in the middle.
> > That's my opinion.
> >
> >
> >
> > Harbs  escreveu no dia terça, 18/10/2022 à(s)
> 08:06:
> >
> >> There’s a sanitizeHTML helper function that’s relatively new.
> >>
> >> I don’t have a strong opinion on whether it should be sanitized by
> default
> >> or that should be the application developer’s responsibility.
> >>
> >> As far as PAYG is concerned, it’s better to put the responsibility on
> the
> >> app developer.
> >>
> >> As far as security is concerned, it would be better to sanitize in the
> >> framework.
> >>
> >> I personally would give precedence to PAYG because the threat of a XSS
> >> attack using innerHTML is a bit of a stretch in Royale.
> >>
> >> We should come up with a policy, document it, and stick to it across the
> >> framework.
> >>
> >> If we do sanitize in the components, it should probably happen in the
> >> model setter.
> >>
> >> What do others think?
> >>
> >>> On Oct 18, 2022, at 2:32 AM, Hugo Ferreira 
> >> wrote:
> >>>
> >>> Thank you very much.
> >>> I see the bug.
> >>> I hope that the Label (html property) that FormHeading that depends on,
> >>> doesn't have the same issue :)
> >>>
> >>> About the sanitize:
> >>> Should this be really a reponsibility of FormHeadingView !?
> >>> Shouldn't the responsibility on one of the edges (the limit of html
> >>> property core or on the end application) ?
> >>> In the middle, we could ending "sanitizing" too much just to be ensure.
> >>>
> >>>
> >>>
> >>> Harbs  escreveu no dia segunda, 17/10/2022 à(s)
> >>> 19:25:
> >>>
>  I assume this is Jewel. I don’t use Jewel, but I just looked at
>  FormHeadingView and textChangeHandler is used for both textChange and
>  htmlChange. In both cases it sets the text rather than html in the
>  htmlChange case. That seems to be broken.
> 
>  If you fix this, make sure the html is sanitized when applied.
> 
>  Harbs
> 
> > On Oct 16, 2022, at 5:17 PM, Hugo Ferreira 
>  wrote:
> >
> > Hi,
> >
> > I'm using FormHeading when I have a lot of fields and want to create
> a
> > vertical separation (group of data).
> > It's OK, however I needed now to use in the FormHeading texto some
> HTML
> > (basic stuff like strong and br), however the property "text" of
> > FormHeading it's for simple real strings and not HTML.
> > I saw the html property, however this property does nothing.
> > It's something that it's not already implemented in the core or I'm
>  missing
> > something ?
> >
> > I saw tht I can workaround, using a pure html:Div with innerHTML but
> I
>  have
> > read in the past that I should avoid it.
> 
> 
> >>
> >>
>
>

Re: HTML

[Harbs]

Let’s see what others think, but in the meantime there’s no reason to not fix 
the bug. There are other html setters which already set innerHTML.

Harbs

> On Oct 18, 2022, at 11:29 PM, Hugo Ferreira  wrote:
> 
> Yes, I saw that helper (I searched for it name) :)
> Yes, it's exactly what I mean: put this in one of the limites of the
> workflow and never in the middle.
> That's my opinion.
> 
> 
> 
> Harbs  escreveu no dia terça, 18/10/2022 à(s) 08:06:
> 
>> There’s a sanitizeHTML helper function that’s relatively new.
>> 
>> I don’t have a strong opinion on whether it should be sanitized by default
>> or that should be the application developer’s responsibility.
>> 
>> As far as PAYG is concerned, it’s better to put the responsibility on the
>> app developer.
>> 
>> As far as security is concerned, it would be better to sanitize in the
>> framework.
>> 
>> I personally would give precedence to PAYG because the threat of a XSS
>> attack using innerHTML is a bit of a stretch in Royale.
>> 
>> We should come up with a policy, document it, and stick to it across the
>> framework.
>> 
>> If we do sanitize in the components, it should probably happen in the
>> model setter.
>> 
>> What do others think?
>> 
>>> On Oct 18, 2022, at 2:32 AM, Hugo Ferreira 
>> wrote:
>>> 
>>> Thank you very much.
>>> I see the bug.
>>> I hope that the Label (html property) that FormHeading that depends on,
>>> doesn't have the same issue :)
>>> 
>>> About the sanitize:
>>> Should this be really a reponsibility of FormHeadingView !?
>>> Shouldn't the responsibility on one of the edges (the limit of html
>>> property core or on the end application) ?
>>> In the middle, we could ending "sanitizing" too much just to be ensure.
>>> 
>>> 
>>> 
>>> Harbs  escreveu no dia segunda, 17/10/2022 à(s)
>>> 19:25:
>>> 
 I assume this is Jewel. I don’t use Jewel, but I just looked at
 FormHeadingView and textChangeHandler is used for both textChange and
 htmlChange. In both cases it sets the text rather than html in the
 htmlChange case. That seems to be broken.
 
 If you fix this, make sure the html is sanitized when applied.
 
 Harbs
 
> On Oct 16, 2022, at 5:17 PM, Hugo Ferreira 
 wrote:
> 
> Hi,
> 
> I'm using FormHeading when I have a lot of fields and want to create a
> vertical separation (group of data).
> It's OK, however I needed now to use in the FormHeading texto some HTML
> (basic stuff like strong and br), however the property "text" of
> FormHeading it's for simple real strings and not HTML.
> I saw the html property, however this property does nothing.
> It's something that it's not already implemented in the core or I'm
 missing
> something ?
> 
> I saw tht I can workaround, using a pure html:Div with innerHTML but I
 have
> read in the past that I should avoid it.
 
 
>> 
>> 

Re: HTML

[Hugo Ferreira]

Yes, I saw that helper (I searched for it name) :)
Yes, it's exactly what I mean: put this in one of the limites of the
workflow and never in the middle.
That's my opinion.



Harbs  escreveu no dia terça, 18/10/2022 à(s) 08:06:

> There’s a sanitizeHTML helper function that’s relatively new.
>
> I don’t have a strong opinion on whether it should be sanitized by default
> or that should be the application developer’s responsibility.
>
> As far as PAYG is concerned, it’s better to put the responsibility on the
> app developer.
>
> As far as security is concerned, it would be better to sanitize in the
> framework.
>
> I personally would give precedence to PAYG because the threat of a XSS
> attack using innerHTML is a bit of a stretch in Royale.
>
> We should come up with a policy, document it, and stick to it across the
> framework.
>
> If we do sanitize in the components, it should probably happen in the
> model setter.
>
> What do others think?
>
> > On Oct 18, 2022, at 2:32 AM, Hugo Ferreira 
> wrote:
> >
> > Thank you very much.
> > I see the bug.
> > I hope that the Label (html property) that FormHeading that depends on,
> > doesn't have the same issue :)
> >
> > About the sanitize:
> > Should this be really a reponsibility of FormHeadingView !?
> > Shouldn't the responsibility on one of the edges (the limit of html
> > property core or on the end application) ?
> > In the middle, we could ending "sanitizing" too much just to be ensure.
> >
> >
> >
> > Harbs  escreveu no dia segunda, 17/10/2022 à(s)
> > 19:25:
> >
> >> I assume this is Jewel. I don’t use Jewel, but I just looked at
> >> FormHeadingView and textChangeHandler is used for both textChange and
> >> htmlChange. In both cases it sets the text rather than html in the
> >> htmlChange case. That seems to be broken.
> >>
> >> If you fix this, make sure the html is sanitized when applied.
> >>
> >> Harbs
> >>
> >>> On Oct 16, 2022, at 5:17 PM, Hugo Ferreira 
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm using FormHeading when I have a lot of fields and want to create a
> >>> vertical separation (group of data).
> >>> It's OK, however I needed now to use in the FormHeading texto some HTML
> >>> (basic stuff like strong and br), however the property "text" of
> >>> FormHeading it's for simple real strings and not HTML.
> >>> I saw the html property, however this property does nothing.
> >>> It's something that it's not already implemented in the core or I'm
> >> missing
> >>> something ?
> >>>
> >>> I saw tht I can workaround, using a pure html:Div with innerHTML but I
> >> have
> >>> read in the past that I should avoid it.
> >>
> >>
>
>

Re: HTML

[Harbs]

There’s a sanitizeHTML helper function that’s relatively new.

I don’t have a strong opinion on whether it should be sanitized by default or 
that should be the application developer’s responsibility.

As far as PAYG is concerned, it’s better to put the responsibility on the app 
developer.

As far as security is concerned, it would be better to sanitize in the 
framework.

I personally would give precedence to PAYG because the threat of a XSS attack 
using innerHTML is a bit of a stretch in Royale.

We should come up with a policy, document it, and stick to it across the 
framework.

If we do sanitize in the components, it should probably happen in the model 
setter.

What do others think?

> On Oct 18, 2022, at 2:32 AM, Hugo Ferreira  wrote:
> 
> Thank you very much.
> I see the bug.
> I hope that the Label (html property) that FormHeading that depends on,
> doesn't have the same issue :)
> 
> About the sanitize:
> Should this be really a reponsibility of FormHeadingView !?
> Shouldn't the responsibility on one of the edges (the limit of html
> property core or on the end application) ?
> In the middle, we could ending "sanitizing" too much just to be ensure.
> 
> 
> 
> Harbs  escreveu no dia segunda, 17/10/2022 à(s)
> 19:25:
> 
>> I assume this is Jewel. I don’t use Jewel, but I just looked at
>> FormHeadingView and textChangeHandler is used for both textChange and
>> htmlChange. In both cases it sets the text rather than html in the
>> htmlChange case. That seems to be broken.
>> 
>> If you fix this, make sure the html is sanitized when applied.
>> 
>> Harbs
>> 
>>> On Oct 16, 2022, at 5:17 PM, Hugo Ferreira 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> I'm using FormHeading when I have a lot of fields and want to create a
>>> vertical separation (group of data).
>>> It's OK, however I needed now to use in the FormHeading texto some HTML
>>> (basic stuff like strong and br), however the property "text" of
>>> FormHeading it's for simple real strings and not HTML.
>>> I saw the html property, however this property does nothing.
>>> It's something that it's not already implemented in the core or I'm
>> missing
>>> something ?
>>> 
>>> I saw tht I can workaround, using a pure html:Div with innerHTML but I
>> have
>>> read in the past that I should avoid it.
>> 
>> 

Re: HTML

[Hugo Ferreira]

Thank you very much.
I see the bug.
I hope that the Label (html property) that FormHeading that depends on,
doesn't have the same issue :)

About the sanitize:
Should this be really a reponsibility of FormHeadingView !?
Shouldn't the responsibility on one of the edges (the limit of html
property core or on the end application) ?
In the middle, we could ending "sanitizing" too much just to be ensure.



Harbs  escreveu no dia segunda, 17/10/2022 à(s)
19:25:

> I assume this is Jewel. I don’t use Jewel, but I just looked at
> FormHeadingView and textChangeHandler is used for both textChange and
> htmlChange. In both cases it sets the text rather than html in the
> htmlChange case. That seems to be broken.
>
> If you fix this, make sure the html is sanitized when applied.
>
> Harbs
>
> > On Oct 16, 2022, at 5:17 PM, Hugo Ferreira 
> wrote:
> >
> > Hi,
> >
> > I'm using FormHeading when I have a lot of fields and want to create a
> > vertical separation (group of data).
> > It's OK, however I needed now to use in the FormHeading texto some HTML
> > (basic stuff like strong and br), however the property "text" of
> > FormHeading it's for simple real strings and not HTML.
> > I saw the html property, however this property does nothing.
> > It's something that it's not already implemented in the core or I'm
> missing
> > something ?
> >
> > I saw tht I can workaround, using a pure html:Div with innerHTML but I
> have
> > read in the past that I should avoid it.
>
>

Re: HTML

[Harbs]

I assume this is Jewel. I don’t use Jewel, but I just looked at FormHeadingView 
and textChangeHandler is used for both textChange and htmlChange. In both cases 
it sets the text rather than html in the htmlChange case. That seems to be 
broken.

If you fix this, make sure the html is sanitized when applied.

Harbs

> On Oct 16, 2022, at 5:17 PM, Hugo Ferreira  wrote:
> 
> Hi,
> 
> I'm using FormHeading when I have a lot of fields and want to create a
> vertical separation (group of data).
> It's OK, however I needed now to use in the FormHeading texto some HTML
> (basic stuff like strong and br), however the property "text" of
> FormHeading it's for simple real strings and not HTML.
> I saw the html property, however this property does nothing.
> It's something that it's not already implemented in the core or I'm missing
> something ?
> 
> I saw tht I can workaround, using a pure html:Div with innerHTML but I have
> read in the past that I should avoid it.