Re: Binding Events issues (was Re: Some questions about Jewel Navigation)
Hi Carlos, The binding system in Flex and Royale has always relied on caught exceptions, so when debugging you often have to turn off "Pause on caught exceptions" which can make things challenging if you are trying to catch some other caught exception. It would be an interesting question to see the cost of adding null checks in all binding generated code. The null check might be faster than the catch. There are always times when binding works despite the compiler warning. The warning is just saying there is at least one scenario where your binding won't work right and if you don't encounter that scenario you are fine. But it will be true in Royale JS output that there are more scenarios where it won't work than in SWF. -Alex On 12/13/18, 1:33 AM, "Carlos Rovira" wrote: Hi Alex El jue., 13 dic. 2018 a las 2:00, Alex Harui () escribió: > > 1) What error do you get with null/undefined in renderers? Really, the error doesn't show clearly on browsers. I could see that in Google Chrome going to Sources and in the right panel check "Pause on caught exceptions" I fixed this in Tour De Jewel (JewelExample), so to see that again you can go to NavigationIconLinkItemRenderer.mxml And in the bindings remove: remove the ternaries and left as it should be Running that in the old state and checking the before mentioned option in chrome will make Tour de Jewel stops at the beginning as each renderer is instantiated and throwing an error. The binding subsystem should have try/catch blocks in the appropriate > places. Maybe we are missing something, or maybe there is a bug, or maybe > there is such a huge cost to automatically protecting against > null/undefined that it is worth folks being a bit more careful about that > in Royale. In the case above, I'm taking care, but IMHO, from a user point of view, I should not have to write a safeguard in each binding. If that's is always required *always*, it seems frameworks responsibility, saving lots of safeguards in users code. This seems to me more PAYG. > Flex did try to evaluate binding expression often whereas Royale will > apply binding at different times to improve performance. Item renderers > are a classic example. In Flex, bindings were evaluated twice before the > data property ever set and a third time when the data finally got set. In > Royale, if you use ItemRendererDataBinding, it only gets evaluated once. > So dig into this a bit more and show us the stack trace (assuming that's > the issue). > Yes, I think is the right way to go, don't thing this issue is a problem with the how many times Royale should check the data, but just how to deal with nulls/undefined. > > 2) There is no limitation in Royale on the maximum level of nested > bindings, but you are probably right that things might work in Flex that > don't work in Royale, again because Flex evaluated binding expressions > quite often, which we don't want to do in Royale for performance reasons. > However, in Flex, and Royale, there is always a chance that you could > change something deep "too late" and then it wouldn't work. But if you > have your change events propagating properly, you can bind to any level in > Royale. If you have a failure case let's take a look at that as well. The > compiler should be telling you that it can't bind to something. > > That's right, I though it was a nested limitation. Knowing is not that is a huge help. I can check in other ways. I'll be warned when I get the next binding issue and we can check it. In the other hand, I remember to see few days ago some bugs in bindings, I think was the compiler warn about a binding that could not be done, but was working, or something like that. Can't remember right now. Again I'll be alert and report here where I find something similar. I think there's still some final little bugs to address in bindings, Maybe Greg could give us more detail on this, if he has some time. I think we're a month to work hard in our app to finish, so maybe at the middle of January we can share more here about our experience and what things we found through our journey so we can think fixes to that -- Carlos Rovira https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7Cc154f8b23bda4728346108d660de072c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802904085592501sdata=LCQ%2Fd%2BGtT86gyV0qw7Ptfge8LSzvweGudkf%2Bz2AgnLA%3Dreserved=0
Re: Binding Events issues (was Re: Some questions about Jewel Navigation)
Hi Alex El jue., 13 dic. 2018 a las 2:00, Alex Harui () escribió: > > 1) What error do you get with null/undefined in renderers? Really, the error doesn't show clearly on browsers. I could see that in Google Chrome going to Sources and in the right panel check "Pause on caught exceptions" I fixed this in Tour De Jewel (JewelExample), so to see that again you can go to NavigationIconLinkItemRenderer.mxml And in the bindings remove: remove the ternaries and left as it should be Running that in the old state and checking the before mentioned option in chrome will make Tour de Jewel stops at the beginning as each renderer is instantiated and throwing an error. The binding subsystem should have try/catch blocks in the appropriate > places. Maybe we are missing something, or maybe there is a bug, or maybe > there is such a huge cost to automatically protecting against > null/undefined that it is worth folks being a bit more careful about that > in Royale. In the case above, I'm taking care, but IMHO, from a user point of view, I should not have to write a safeguard in each binding. If that's is always required *always*, it seems frameworks responsibility, saving lots of safeguards in users code. This seems to me more PAYG. > Flex did try to evaluate binding expression often whereas Royale will > apply binding at different times to improve performance. Item renderers > are a classic example. In Flex, bindings were evaluated twice before the > data property ever set and a third time when the data finally got set. In > Royale, if you use ItemRendererDataBinding, it only gets evaluated once. > So dig into this a bit more and show us the stack trace (assuming that's > the issue). > Yes, I think is the right way to go, don't thing this issue is a problem with the how many times Royale should check the data, but just how to deal with nulls/undefined. > > 2) There is no limitation in Royale on the maximum level of nested > bindings, but you are probably right that things might work in Flex that > don't work in Royale, again because Flex evaluated binding expressions > quite often, which we don't want to do in Royale for performance reasons. > However, in Flex, and Royale, there is always a chance that you could > change something deep "too late" and then it wouldn't work. But if you > have your change events propagating properly, you can bind to any level in > Royale. If you have a failure case let's take a look at that as well. The > compiler should be telling you that it can't bind to something. > > That's right, I though it was a nested limitation. Knowing is not that is a huge help. I can check in other ways. I'll be warned when I get the next binding issue and we can check it. In the other hand, I remember to see few days ago some bugs in bindings, I think was the compiler warn about a binding that could not be done, but was working, or something like that. Can't remember right now. Again I'll be alert and report here where I find something similar. I think there's still some final little bugs to address in bindings, Maybe Greg could give us more detail on this, if he has some time. I think we're a month to work hard in our app to finish, so maybe at the middle of January we can share more here about our experience and what things we found through our journey so we can think fixes to that -- Carlos Rovira http://about.me/carlosrovira
Re: Binding Events issues (was Re: Some questions about Jewel Navigation)
I'm first going to answer Greg's question from the other thread since it is
probably wise to rename this thread.
Greg asked: "Am I right in interpreting what you say as being that there should
be more
event types for binding at the component level? (not just 'change', but
selectedIndexChanged, and selectedItemChanged as well?)"
I would say yes, as long as we are careful about PAYG. As with any change we
want to look at how much code gets added "just-in-case". What I mean by that
is that we don't want to go through the code and blindly add more change
events. Let's look at the actual implementation patterns:
-IMO, the "change" interaction event (or similarly named event) should be
dispatched by a Controller, not the model.
-A model is not required to dispatch change events. The simplest "dumbest"
model will take an array of strings that is not supplied "late" by a server and
thus the lifecycle can promise that the model is ready to go when the view
needs it, and will not change at runtime.
-Other models can change at runtime and should dispatch binding change events
if needed. By default, that would be "somePropertyChanged" (note that Flex
used "somePropertyChange", I personally don't care about the tense) but not all
properties must fire a uniquely named event. SelectedItem and SelectedIndex
are usually related so a single "selectionChange" event should be dispatched.
There may be other situations where a bunch of properties change and then there
is some final property change that "commits" it, and maybe only that property
needs to dispatch an event. We don't want to dispatch a ton of events
just-in-case if we can avoid it. Nor do we want to carry code around that
dispatches those events. The pattern of using hasEventListener can be used but
doesn't seem lightweight enough to be used everywhere. Because everything is
replaceable in Royale, if someone needs a model that dispatches more events,
they can always create such a model. We want to find the balance between
handling the right percentage of cases for the right amount of code. The Flex
philosophy was more about trying to handle nearly 100% of case by adding as
much code as we had time for. But that results in too much just-in-case code.
So that's where the code goes, but then you need [Bindable("eventName")]
metadata. The cost of Bindable metadata in JS is significant, but it all ends
up in a data structure that can be removed from the code by Closure Compiler.
But if it any code in a compilation needs the Metadata, then all of it is kept
in every class in the compilation. But if you already have one metadata on an
API, adding a second isn't much more expensive than adding that string to the
output. So I think it shouldn't be a huge impact to add both "selectionChange"
and "change" as metadata on an API.
OK, now to Carlos's questions:
1) What error do you get with null/undefined in renderers? The binding
subsystem should have try/catch blocks in the appropriate places. Maybe we are
missing something, or maybe there is a bug, or maybe there is such a huge cost
to automatically protecting against null/undefined that it is worth folks being
a bit more careful about that in Royale. Flex did try to evaluate binding
expression often whereas Royale will apply binding at different times to
improve performance. Item renderers are a classic example. In Flex, bindings
were evaluated twice before the data property ever set and a third time when
the data finally got set. In Royale, if you use ItemRendererDataBinding, it
only gets evaluated once. So dig into this a bit more and show us the stack
trace (assuming that's the issue).
2) There is no limitation in Royale on the maximum level of nested bindings,
but you are probably right that things might work in Flex that don't work in
Royale, again because Flex evaluated binding expressions quite often, which we
don't want to do in Royale for performance reasons. However, in Flex, and
Royale, there is always a chance that you could change something deep "too
late" and then it wouldn't work. But if you have your change events
propagating properly, you can bind to any level in Royale. If you have a
failure case let's take a look at that as well. The compiler should be telling
you that it can't bind to something.
HTH,
-Alex
On 12/12/18, 2:19 PM, "Carlos Rovira" wrote:
Hi Alex,
regarding Binding Events, our experience is that is a bit more hard to work
with them in Royale than in Flex. The main issues we are experiencing are:
1.- In almost all renderers we need to check for null/undefined while in
flex is not needed:
text="{optionPack ? optionPack.description : ''}"
the getter in that renderer is
[Bindable(event="dataChange")]
public function get optionPack():Base7OptionPack
{
return data as Base7OptionPack;
}
Re: Some questions about Jewel Navigation
There shouldn't be a need to dispatch "change" until someone interacts with the component. Differentiating between the two usually helps make setup code simpler. You can assign initial values to things without reacting everywhere to the change. The issue in general was related to binding, which was based on change events. And the broader context is in relation to porting legacy flex code while minimizing the changes to the code. Am I right in interpreting what you say as being that there should be more event types for binding at the component level? (not just 'change', but selectedIndexChanged, and selectedItemChanged as well?) On Thu, Dec 13, 2018 at 10:54 AM Alex Harui wrote: > I may have missed something, and DispatchChangeOnStartup is a proper bead, > especially for a first attempt, but theoretically, it shouldn't be needed. > > There are different categories of events in Flex and Royale. I'm not sure > there is a complete list of categories, but ones that pop to mind are: > > 1) Low-level interaction events > 2) Higher-level interaction events > 3) Binding events. > > Things like mouseDown and mouseUp are low-level interaction events. CLICK > and CHANGE are higher-level interaction events. They imply that some > series of interactions occurred (CLICK= mouseDown+mouseUp). ITEM_CLICK is > even higher level, it implies that a click occurred on an ItemRenderer and > not, say, the scrollbar button in a List. Thus, writing code to dispatch > CHANGE events outside of controller logic is roughly equivalent to faking > mouse and keyboard events. Sometimes you gotta do it, but usually it > implies that something else isn't quite right. > > Sometimes it helps to think about whether such a thing was needed in Flex > and how similar setups worked there. It could be Royale is missing > something, or something isn't quite right yet. In fact, the Royale binding > system is trying to be less aggressive and thus have less overhead than > Flex, but theoretically, the flow of binding events should propagate > properly to all concerned, so it would be interesting to really understand > why such a thing was needed. Maybe something is truly only needed at > startup, but often these things end up being needed elsewhere "later" like > on state changes or module loads. > > The binding system in Royale can handle multiple events. Models are PAYG, > so some models expect runtime changes and simpler ones don't to save on > cost. But for models that expect runtime changes (required for any model > representing asynchronous data loading), the binding events should > propagate appropriately. Flex used (or maybe overused) VALUE_COMMIT > events. We can do that, but right now the pattern is to make a unique > event name. So selectedIndex should dispatch selectedIndexChanged no > matter how it got changed and that should propagate through other > bindings. When the dataProvider changes, if that affects the > selectedIndex, then the model should set the selectedIndex and dispatch > selectedIndexChanged. There shouldn't be a need to dispatch "change" until > someone interacts with the component. Differentiating between the two > usually helps make setup code simpler. You can assign initial values to > things without reacting everywhere to the change. > > Of course, I could be wrong. > HTH, > -Alex > > > On 12/12/18, 10:55 AM, "Greg Dove" wrote: > > I made changes to address some issues, but I no doubt used the wrong > pattern, sorry guys. > I have mainly focused on non-UI code in the past, or custom UI > components > without beads in some other work I did last year so 'beads' is still > something I am getting used to (although composition in general is > not). > > I never wrote any actual beads before DispatchChangeOnStartup, that > was the > first bead I ever wrote and may still not be 'right', it was a quick > fix > for a specific case and I did not have time to go back and > review/refactor > what I did elsewhere to get the lists working for programmatic changes. > > Piotr, thanks for looking into this. In terms of 'double dispatch' I > also > remember seeing somewhere that there are some overrides that dispatch > events but call the super setter that also dispatches the same event. > I did > not have time to look into that in more detail. That could be in > renderers > with 'dataChange' iirc ... not related to what you are looking at, but > that > just made me think of it. > > I will be happy to look more into these things and contribute more to > Jewel > in time, when I also get some free time. > > > > > On Thu, Dec 13, 2018 at 1:24 AM Piotr Zarzycki < > piotrzarzyck...@gmail.com> > wrote: > > > Yep - I just did quick look into the bead and it's essentially have > those > > things which are currently baked into Model. I hopefully remove that > one > > and replace things using bead in Jewel Example. > > > >
Binding Events issues (was Re: Some questions about Jewel Navigation)
Hi Alex,
regarding Binding Events, our experience is that is a bit more hard to work
with them in Royale than in Flex. The main issues we are experiencing are:
1.- In almost all renderers we need to check for null/undefined while in
flex is not needed:
text="{optionPack ? optionPack.description : ''}"
the getter in that renderer is
[Bindable(event="dataChange")]
public function get optionPack():Base7OptionPack
{
return data as Base7OptionPack;
}
migrated from Flex 100% equal
I expect to bind in the following way:
text="{optionPack.description}"
I think our user code will be more PAYG if renderers consider it self the
nulls/undefineds, instead to make users to make consider in almost any
binding.
2.- Level of nested bindings
I think the maximum level of nested properties accessed in a binding is
around 3.
So {foo.woo.zoo} can work but {foo.woo.zoo.noo} will not, while in flex
workd
I think that's the two main issue we see in this real world Apache Royale
project we are immerse now.
Thanks
El mié., 12 dic. 2018 a las 22:54, Alex Harui ()
escribió:
> I may have missed something, and DispatchChangeOnStartup is a proper bead,
> especially for a first attempt, but theoretically, it shouldn't be needed.
>
> There are different categories of events in Flex and Royale. I'm not sure
> there is a complete list of categories, but ones that pop to mind are:
>
> 1) Low-level interaction events
> 2) Higher-level interaction events
> 3) Binding events.
>
> Things like mouseDown and mouseUp are low-level interaction events. CLICK
> and CHANGE are higher-level interaction events. They imply that some
> series of interactions occurred (CLICK= mouseDown+mouseUp). ITEM_CLICK is
> even higher level, it implies that a click occurred on an ItemRenderer and
> not, say, the scrollbar button in a List. Thus, writing code to dispatch
> CHANGE events outside of controller logic is roughly equivalent to faking
> mouse and keyboard events. Sometimes you gotta do it, but usually it
> implies that something else isn't quite right.
>
> Sometimes it helps to think about whether such a thing was needed in Flex
> and how similar setups worked there. It could be Royale is missing
> something, or something isn't quite right yet. In fact, the Royale binding
> system is trying to be less aggressive and thus have less overhead than
> Flex, but theoretically, the flow of binding events should propagate
> properly to all concerned, so it would be interesting to really understand
> why such a thing was needed. Maybe something is truly only needed at
> startup, but often these things end up being needed elsewhere "later" like
> on state changes or module loads.
>
> The binding system in Royale can handle multiple events. Models are PAYG,
> so some models expect runtime changes and simpler ones don't to save on
> cost. But for models that expect runtime changes (required for any model
> representing asynchronous data loading), the binding events should
> propagate appropriately. Flex used (or maybe overused) VALUE_COMMIT
> events. We can do that, but right now the pattern is to make a unique
> event name. So selectedIndex should dispatch selectedIndexChanged no
> matter how it got changed and that should propagate through other
> bindings. When the dataProvider changes, if that affects the
> selectedIndex, then the model should set the selectedIndex and dispatch
> selectedIndexChanged. There shouldn't be a need to dispatch "change" until
> someone interacts with the component. Differentiating between the two
> usually helps make setup code simpler. You can assign initial values to
> things without reacting everywhere to the change.
>
> Of course, I could be wrong.
> HTH,
> -Alex
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Some questions about Jewel Navigation
I may have missed something, and DispatchChangeOnStartup is a proper bead, especially for a first attempt, but theoretically, it shouldn't be needed. There are different categories of events in Flex and Royale. I'm not sure there is a complete list of categories, but ones that pop to mind are: 1) Low-level interaction events 2) Higher-level interaction events 3) Binding events. Things like mouseDown and mouseUp are low-level interaction events. CLICK and CHANGE are higher-level interaction events. They imply that some series of interactions occurred (CLICK= mouseDown+mouseUp). ITEM_CLICK is even higher level, it implies that a click occurred on an ItemRenderer and not, say, the scrollbar button in a List. Thus, writing code to dispatch CHANGE events outside of controller logic is roughly equivalent to faking mouse and keyboard events. Sometimes you gotta do it, but usually it implies that something else isn't quite right. Sometimes it helps to think about whether such a thing was needed in Flex and how similar setups worked there. It could be Royale is missing something, or something isn't quite right yet. In fact, the Royale binding system is trying to be less aggressive and thus have less overhead than Flex, but theoretically, the flow of binding events should propagate properly to all concerned, so it would be interesting to really understand why such a thing was needed. Maybe something is truly only needed at startup, but often these things end up being needed elsewhere "later" like on state changes or module loads. The binding system in Royale can handle multiple events. Models are PAYG, so some models expect runtime changes and simpler ones don't to save on cost. But for models that expect runtime changes (required for any model representing asynchronous data loading), the binding events should propagate appropriately. Flex used (or maybe overused) VALUE_COMMIT events. We can do that, but right now the pattern is to make a unique event name. So selectedIndex should dispatch selectedIndexChanged no matter how it got changed and that should propagate through other bindings. When the dataProvider changes, if that affects the selectedIndex, then the model should set the selectedIndex and dispatch selectedIndexChanged. There shouldn't be a need to dispatch "change" until someone interacts with the component. Differentiating between the two usually helps make setup code simpler. You can assign initial values to things without reacting everywhere to the change. Of course, I could be wrong. HTH, -Alex On 12/12/18, 10:55 AM, "Greg Dove" wrote: I made changes to address some issues, but I no doubt used the wrong pattern, sorry guys. I have mainly focused on non-UI code in the past, or custom UI components without beads in some other work I did last year so 'beads' is still something I am getting used to (although composition in general is not). I never wrote any actual beads before DispatchChangeOnStartup, that was the first bead I ever wrote and may still not be 'right', it was a quick fix for a specific case and I did not have time to go back and review/refactor what I did elsewhere to get the lists working for programmatic changes. Piotr, thanks for looking into this. In terms of 'double dispatch' I also remember seeing somewhere that there are some overrides that dispatch events but call the super setter that also dispatches the same event. I did not have time to look into that in more detail. That could be in renderers with 'dataChange' iirc ... not related to what you are looking at, but that just made me think of it. I will be happy to look more into these things and contribute more to Jewel in time, when I also get some free time. On Thu, Dec 13, 2018 at 1:24 AM Piotr Zarzycki wrote: > Yep - I just did quick look into the bead and it's essentially have those > things which are currently baked into Model. I hopefully remove that one > and replace things using bead in Jewel Example. > > Thanks for adding that! > Piotr > > śr., 12 gru 2018 o 13:04 Carlos Rovira > napisał(a): > > > Hi Piotr, > > > > just migrated the bead I talked (DispatchChangeOnStartup) from our > project > > to royale so you can have all the pieces and help you to diagnose the > > problem > > > > As I said you Greg did the latest changes on this components so I should > as > > well read the changes since I didn't have to analyze since that was > working > > in our app in many parts flawlessly. > > > > thanks for taking care and good luck > > > > :) > > > > El mié., 12 dic. 2018 a las 10:55, Piotr Zarzycki (< > > piotrzarzyck...@gmail.com>) escribió: > > > > > Hi Carlos, > > > > > > Comments inline. > > > > > > śr., 12 gru
Re: Some questions about Jewel Navigation
I made changes to address some issues, but I no doubt used the wrong pattern, sorry guys. I have mainly focused on non-UI code in the past, or custom UI components without beads in some other work I did last year so 'beads' is still something I am getting used to (although composition in general is not). I never wrote any actual beads before DispatchChangeOnStartup, that was the first bead I ever wrote and may still not be 'right', it was a quick fix for a specific case and I did not have time to go back and review/refactor what I did elsewhere to get the lists working for programmatic changes. Piotr, thanks for looking into this. In terms of 'double dispatch' I also remember seeing somewhere that there are some overrides that dispatch events but call the super setter that also dispatches the same event. I did not have time to look into that in more detail. That could be in renderers with 'dataChange' iirc ... not related to what you are looking at, but that just made me think of it. I will be happy to look more into these things and contribute more to Jewel in time, when I also get some free time. On Thu, Dec 13, 2018 at 1:24 AM Piotr Zarzycki wrote: > Yep - I just did quick look into the bead and it's essentially have those > things which are currently baked into Model. I hopefully remove that one > and replace things using bead in Jewel Example. > > Thanks for adding that! > Piotr > > śr., 12 gru 2018 o 13:04 Carlos Rovira > napisał(a): > > > Hi Piotr, > > > > just migrated the bead I talked (DispatchChangeOnStartup) from our > project > > to royale so you can have all the pieces and help you to diagnose the > > problem > > > > As I said you Greg did the latest changes on this components so I should > as > > well read the changes since I didn't have to analyze since that was > working > > in our app in many parts flawlessly. > > > > thanks for taking care and good luck > > > > :) > > > > El mié., 12 dic. 2018 a las 10:55, Piotr Zarzycki (< > > piotrzarzyck...@gmail.com>) escribió: > > > > > Hi Carlos, > > > > > > Comments inline. > > > > > > śr., 12 gru 2018 o 10:44 Carlos Rovira > > > napisał(a): > > > > > > > Hi Piotr, > > > > > > > > This month Greg and I made some changes to get selectedIndex and > > > > selectedItem work in List, ComboBox and DropDownList. Since > Navigation > > > is a > > > > List in essence, is involved in this changes. We should see how to > > avoid > > > > the duplicated event without lost the current workflow that now is > > > working > > > > properly like it was in flex days. Was hard to reach to that point. > > > > > > > > About options, we already have a bead to dispatch a change event on > > > startup > > > > in our project that we must pass to Jewel library. But I think is not > > > what > > > > we want here. We want setting selectedIndex/selectedItem in mxml > should > > > put > > > > the component in proper state. I think that's what you refer when > talk > > > > about getting to work "programmatically" right? > > > > > > > > > > > *Generally yes those actions should put component in proper state, but > I > > > just feeling that those state should not be achieved through model > which > > > dispatch "change" event. "change" event is to tell user that someone > > > interact with component from UI. If developer interacting through code > > > selectedIndexChanged and selectedItemChanged should probably come with > > > help.* > > > > > > > > > > Basically I think we have all needed beads in place, So I'll try the > > > > removal option. But I think that event was copied from Basic version, > > so > > > > maybe is right (can ensure right now). You can try to do it yourself. > > You > > > > should check Jewel Example (Tour de Jewel) and specially List, > ComboBox > > > and > > > > DropDownList sections along Navigation (that is used in the drawer) > and > > > > check you don't see regressions when doing changes. See how the > > examples > > > > behave actually, and since debugger now works perfectly, you can put > > > break > > > > points to see where's the problem and how to diagnose the right > > solution. > > > > > > > > > > > *Yes ArrayListSelectionModel is essentially copy of Basic one, but you > > have > > > added there code which dispatch "change" event plus property which > > > generally allows you to do this or not > > (dispatchChangeOnDataProviderChange) > > > - That whole part even if should exists - should be probably exposed to > > > separate bead. * > > > *I'm surprised that you don't have any problems using in your > > applications > > > Bead for dispatch "change" event + ListSingleSelectionMouseController > > (it > > > also dispatch that event) + model - All are able to dispatch change in > > > almost the same cases!* > > > > > > *Ok I think I will have to work on that with all cautious to current > > code.* > > > > > > > > > > Thanks! :) > > > > > > > > > > > > > > > > > > > > El mar., 11 dic. 2018 a las 23:49, Piotr Zarzycki (< > > > >
Re: Some questions about Jewel Navigation
Yep - I just did quick look into the bead and it's essentially have those things which are currently baked into Model. I hopefully remove that one and replace things using bead in Jewel Example. Thanks for adding that! Piotr śr., 12 gru 2018 o 13:04 Carlos Rovira napisał(a): > Hi Piotr, > > just migrated the bead I talked (DispatchChangeOnStartup) from our project > to royale so you can have all the pieces and help you to diagnose the > problem > > As I said you Greg did the latest changes on this components so I should as > well read the changes since I didn't have to analyze since that was working > in our app in many parts flawlessly. > > thanks for taking care and good luck > > :) > > El mié., 12 dic. 2018 a las 10:55, Piotr Zarzycki (< > piotrzarzyck...@gmail.com>) escribió: > > > Hi Carlos, > > > > Comments inline. > > > > śr., 12 gru 2018 o 10:44 Carlos Rovira > > napisał(a): > > > > > Hi Piotr, > > > > > > This month Greg and I made some changes to get selectedIndex and > > > selectedItem work in List, ComboBox and DropDownList. Since Navigation > > is a > > > List in essence, is involved in this changes. We should see how to > avoid > > > the duplicated event without lost the current workflow that now is > > working > > > properly like it was in flex days. Was hard to reach to that point. > > > > > > About options, we already have a bead to dispatch a change event on > > startup > > > in our project that we must pass to Jewel library. But I think is not > > what > > > we want here. We want setting selectedIndex/selectedItem in mxml should > > put > > > the component in proper state. I think that's what you refer when talk > > > about getting to work "programmatically" right? > > > > > > > > *Generally yes those actions should put component in proper state, but I > > just feeling that those state should not be achieved through model which > > dispatch "change" event. "change" event is to tell user that someone > > interact with component from UI. If developer interacting through code > > selectedIndexChanged and selectedItemChanged should probably come with > > help.* > > > > > > > Basically I think we have all needed beads in place, So I'll try the > > > removal option. But I think that event was copied from Basic version, > so > > > maybe is right (can ensure right now). You can try to do it yourself. > You > > > should check Jewel Example (Tour de Jewel) and specially List, ComboBox > > and > > > DropDownList sections along Navigation (that is used in the drawer) and > > > check you don't see regressions when doing changes. See how the > examples > > > behave actually, and since debugger now works perfectly, you can put > > break > > > points to see where's the problem and how to diagnose the right > solution. > > > > > > > > *Yes ArrayListSelectionModel is essentially copy of Basic one, but you > have > > added there code which dispatch "change" event plus property which > > generally allows you to do this or not > (dispatchChangeOnDataProviderChange) > > - That whole part even if should exists - should be probably exposed to > > separate bead. * > > *I'm surprised that you don't have any problems using in your > applications > > Bead for dispatch "change" event + ListSingleSelectionMouseController > (it > > also dispatch that event) + model - All are able to dispatch change in > > almost the same cases!* > > > > *Ok I think I will have to work on that with all cautious to current > code.* > > > > > > > Thanks! :) > > > > > > > > > > > > > > > El mar., 11 dic. 2018 a las 23:49, Piotr Zarzycki (< > > > piotrzarzyck...@gmail.com>) escribió: > > > > > > > Carlos, > > > > > > > > I just looked into the problem with double call of change event. You > > are > > > > using as default ListSingleSelectionMouseController - in navigation > > > > component which is calling "change" event once someone is clicking on > > > item. > > > > > > > > However you are doing it again from ArrayListSelectionModel which > > > probably > > > > shouldn't happen. This model is calling only selectedItemChanged, > > > > *selectedIndexChanged. * > > > > > > > > I'm assuming you are calling "change" event in > ArrayListSelectionModel > > > > cause you wanted to know whether someone has changed selectedItem and > > > > selectedIndex programmatically . If that was the case you should > > create a > > > > bead which listening for events from model and react in specific way. > > > > > > > > My proposition is: > > > > 1) Remove call of change event from Jewel ArrayListSelectionModel > > > > 2) Create a bead if you need for operation of programmatic change - > in > > > that > > > > case do not use in parallel ListSingleSelectionMouseController > > > > > > > > Thoughts ? > > > > > > > > Thanks, > > > > Piotr > > > > > > > > wt., 11 gru 2018 o 22:13 Carlos Rovira > > > > napisał(a): > > > > > > > > > Hi Piotr, > > > > > > > > > > but .nav will not do anything. As I write before the right things > > > should > > > > be > > > >
Re: Some questions about Jewel Navigation
Hi Piotr, just migrated the bead I talked (DispatchChangeOnStartup) from our project to royale so you can have all the pieces and help you to diagnose the problem As I said you Greg did the latest changes on this components so I should as well read the changes since I didn't have to analyze since that was working in our app in many parts flawlessly. thanks for taking care and good luck :) El mié., 12 dic. 2018 a las 10:55, Piotr Zarzycki (< piotrzarzyck...@gmail.com>) escribió: > Hi Carlos, > > Comments inline. > > śr., 12 gru 2018 o 10:44 Carlos Rovira > napisał(a): > > > Hi Piotr, > > > > This month Greg and I made some changes to get selectedIndex and > > selectedItem work in List, ComboBox and DropDownList. Since Navigation > is a > > List in essence, is involved in this changes. We should see how to avoid > > the duplicated event without lost the current workflow that now is > working > > properly like it was in flex days. Was hard to reach to that point. > > > > About options, we already have a bead to dispatch a change event on > startup > > in our project that we must pass to Jewel library. But I think is not > what > > we want here. We want setting selectedIndex/selectedItem in mxml should > put > > the component in proper state. I think that's what you refer when talk > > about getting to work "programmatically" right? > > > > > *Generally yes those actions should put component in proper state, but I > just feeling that those state should not be achieved through model which > dispatch "change" event. "change" event is to tell user that someone > interact with component from UI. If developer interacting through code > selectedIndexChanged and selectedItemChanged should probably come with > help.* > > > > Basically I think we have all needed beads in place, So I'll try the > > removal option. But I think that event was copied from Basic version, so > > maybe is right (can ensure right now). You can try to do it yourself. You > > should check Jewel Example (Tour de Jewel) and specially List, ComboBox > and > > DropDownList sections along Navigation (that is used in the drawer) and > > check you don't see regressions when doing changes. See how the examples > > behave actually, and since debugger now works perfectly, you can put > break > > points to see where's the problem and how to diagnose the right solution. > > > > > *Yes ArrayListSelectionModel is essentially copy of Basic one, but you have > added there code which dispatch "change" event plus property which > generally allows you to do this or not (dispatchChangeOnDataProviderChange) > - That whole part even if should exists - should be probably exposed to > separate bead. * > *I'm surprised that you don't have any problems using in your applications > Bead for dispatch "change" event + ListSingleSelectionMouseController (it > also dispatch that event) + model - All are able to dispatch change in > almost the same cases!* > > *Ok I think I will have to work on that with all cautious to current code.* > > > > Thanks! :) > > > > > > > > > > El mar., 11 dic. 2018 a las 23:49, Piotr Zarzycki (< > > piotrzarzyck...@gmail.com>) escribió: > > > > > Carlos, > > > > > > I just looked into the problem with double call of change event. You > are > > > using as default ListSingleSelectionMouseController - in navigation > > > component which is calling "change" event once someone is clicking on > > item. > > > > > > However you are doing it again from ArrayListSelectionModel which > > probably > > > shouldn't happen. This model is calling only selectedItemChanged, > > > *selectedIndexChanged. * > > > > > > I'm assuming you are calling "change" event in ArrayListSelectionModel > > > cause you wanted to know whether someone has changed selectedItem and > > > selectedIndex programmatically . If that was the case you should > create a > > > bead which listening for events from model and react in specific way. > > > > > > My proposition is: > > > 1) Remove call of change event from Jewel ArrayListSelectionModel > > > 2) Create a bead if you need for operation of programmatic change - in > > that > > > case do not use in parallel ListSingleSelectionMouseController > > > > > > Thoughts ? > > > > > > Thanks, > > > Piotr > > > > > > wt., 11 gru 2018 o 22:13 Carlos Rovira > > > napisał(a): > > > > > > > Hi Piotr, > > > > > > > > but .nav will not do anything. As I write before the right things > > should > > > be > > > > > > > > .jewel.navigation > > > > background-color: transparent > > > > > > > > This in you App css will win over the one in the theme. > > > > > > > > Didn't try, but that should work, at least is what I do when I want > > some > > > > quick change to try or something temporal, or even could be a final > > > change > > > > too depending on the case. > > > > > > > > > > > > El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (< > > > > piotrzarzyck...@gmail.com>) escribió: > > > > > > > > > I have tried to do point #2 from your options, but
Re: Some questions about Jewel Navigation
Hi Carlos,
Comments inline.
śr., 12 gru 2018 o 10:44 Carlos Rovira
napisał(a):
> Hi Piotr,
>
> This month Greg and I made some changes to get selectedIndex and
> selectedItem work in List, ComboBox and DropDownList. Since Navigation is a
> List in essence, is involved in this changes. We should see how to avoid
> the duplicated event without lost the current workflow that now is working
> properly like it was in flex days. Was hard to reach to that point.
>
> About options, we already have a bead to dispatch a change event on startup
> in our project that we must pass to Jewel library. But I think is not what
> we want here. We want setting selectedIndex/selectedItem in mxml should put
> the component in proper state. I think that's what you refer when talk
> about getting to work "programmatically" right?
>
>
*Generally yes those actions should put component in proper state, but I
just feeling that those state should not be achieved through model which
dispatch "change" event. "change" event is to tell user that someone
interact with component from UI. If developer interacting through code
selectedIndexChanged and selectedItemChanged should probably come with
help.*
> Basically I think we have all needed beads in place, So I'll try the
> removal option. But I think that event was copied from Basic version, so
> maybe is right (can ensure right now). You can try to do it yourself. You
> should check Jewel Example (Tour de Jewel) and specially List, ComboBox and
> DropDownList sections along Navigation (that is used in the drawer) and
> check you don't see regressions when doing changes. See how the examples
> behave actually, and since debugger now works perfectly, you can put break
> points to see where's the problem and how to diagnose the right solution.
>
>
*Yes ArrayListSelectionModel is essentially copy of Basic one, but you have
added there code which dispatch "change" event plus property which
generally allows you to do this or not (dispatchChangeOnDataProviderChange)
- That whole part even if should exists - should be probably exposed to
separate bead. *
*I'm surprised that you don't have any problems using in your applications
Bead for dispatch "change" event + ListSingleSelectionMouseController (it
also dispatch that event) + model - All are able to dispatch change in
almost the same cases!*
*Ok I think I will have to work on that with all cautious to current code.*
> Thanks! :)
>
>
>
>
> El mar., 11 dic. 2018 a las 23:49, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > Carlos,
> >
> > I just looked into the problem with double call of change event. You are
> > using as default ListSingleSelectionMouseController - in navigation
> > component which is calling "change" event once someone is clicking on
> item.
> >
> > However you are doing it again from ArrayListSelectionModel which
> probably
> > shouldn't happen. This model is calling only selectedItemChanged,
> > *selectedIndexChanged. *
> >
> > I'm assuming you are calling "change" event in ArrayListSelectionModel
> > cause you wanted to know whether someone has changed selectedItem and
> > selectedIndex programmatically . If that was the case you should create a
> > bead which listening for events from model and react in specific way.
> >
> > My proposition is:
> > 1) Remove call of change event from Jewel ArrayListSelectionModel
> > 2) Create a bead if you need for operation of programmatic change - in
> that
> > case do not use in parallel ListSingleSelectionMouseController
> >
> > Thoughts ?
> >
> > Thanks,
> > Piotr
> >
> > wt., 11 gru 2018 o 22:13 Carlos Rovira
> > napisał(a):
> >
> > > Hi Piotr,
> > >
> > > but .nav will not do anything. As I write before the right things
> should
> > be
> > >
> > > .jewel.navigation
> > > background-color: transparent
> > >
> > > This in you App css will win over the one in the theme.
> > >
> > > Didn't try, but that should work, at least is what I do when I want
> some
> > > quick change to try or something temporal, or even could be a final
> > change
> > > too depending on the case.
> > >
> > >
> > > El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
> > > piotrzarzyck...@gmail.com>) escribió:
> > >
> > > > I have tried to do point #2 from your options, but when I declare my
> > own
> > > > class:
> > > >
> > > > .nav {
> > > > background-color: #ff
> > > > }
> > > >
> > > > It's being override by those one from framework. Maybe I have to
> > > inherited
> > > > from framework classes ?
> > > >
> > > > Thanks, Piotr
> > > >
> > > > wt., 11 gru 2018 o 20:44 Carlos Rovira
> > > > napisał(a):
> > > >
> > > > > Hi Piotr,
> > > > >
> > > > > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> > > > > piotrzarzyck...@gmail.com>) escribió:
> > > > >
> > > > > > Hi Carlos,
> > > > > >
> > > > > > I have started playing using Jewel lately more serious and have
> two
> > > > > > questions related to Jewel Navigation component.
> > > > > >
> > > > > > I'm displaying
Re: Some questions about Jewel Navigation
Hi Piotr,
This month Greg and I made some changes to get selectedIndex and
selectedItem work in List, ComboBox and DropDownList. Since Navigation is a
List in essence, is involved in this changes. We should see how to avoid
the duplicated event without lost the current workflow that now is working
properly like it was in flex days. Was hard to reach to that point.
About options, we already have a bead to dispatch a change event on startup
in our project that we must pass to Jewel library. But I think is not what
we want here. We want setting selectedIndex/selectedItem in mxml should put
the component in proper state. I think that's what you refer when talk
about getting to work "programmatically" right?
Basically I think we have all needed beads in place, So I'll try the
removal option. But I think that event was copied from Basic version, so
maybe is right (can ensure right now). You can try to do it yourself. You
should check Jewel Example (Tour de Jewel) and specially List, ComboBox and
DropDownList sections along Navigation (that is used in the drawer) and
check you don't see regressions when doing changes. See how the examples
behave actually, and since debugger now works perfectly, you can put break
points to see where's the problem and how to diagnose the right solution.
Thanks! :)
El mar., 11 dic. 2018 a las 23:49, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:
> Carlos,
>
> I just looked into the problem with double call of change event. You are
> using as default ListSingleSelectionMouseController - in navigation
> component which is calling "change" event once someone is clicking on item.
>
> However you are doing it again from ArrayListSelectionModel which probably
> shouldn't happen. This model is calling only selectedItemChanged,
> *selectedIndexChanged. *
>
> I'm assuming you are calling "change" event in ArrayListSelectionModel
> cause you wanted to know whether someone has changed selectedItem and
> selectedIndex programmatically . If that was the case you should create a
> bead which listening for events from model and react in specific way.
>
> My proposition is:
> 1) Remove call of change event from Jewel ArrayListSelectionModel
> 2) Create a bead if you need for operation of programmatic change - in that
> case do not use in parallel ListSingleSelectionMouseController
>
> Thoughts ?
>
> Thanks,
> Piotr
>
> wt., 11 gru 2018 o 22:13 Carlos Rovira
> napisał(a):
>
> > Hi Piotr,
> >
> > but .nav will not do anything. As I write before the right things should
> be
> >
> > .jewel.navigation
> > background-color: transparent
> >
> > This in you App css will win over the one in the theme.
> >
> > Didn't try, but that should work, at least is what I do when I want some
> > quick change to try or something temporal, or even could be a final
> change
> > too depending on the case.
> >
> >
> > El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
> > piotrzarzyck...@gmail.com>) escribió:
> >
> > > I have tried to do point #2 from your options, but when I declare my
> own
> > > class:
> > >
> > > .nav {
> > > background-color: #ff
> > > }
> > >
> > > It's being override by those one from framework. Maybe I have to
> > inherited
> > > from framework classes ?
> > >
> > > Thanks, Piotr
> > >
> > > wt., 11 gru 2018 o 20:44 Carlos Rovira
> > > napisał(a):
> > >
> > > > Hi Piotr,
> > > >
> > > > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> > > > piotrzarzyck...@gmail.com>) escribió:
> > > >
> > > > > Hi Carlos,
> > > > >
> > > > > I have started playing using Jewel lately more serious and have two
> > > > > questions related to Jewel Navigation component.
> > > > >
> > > > > I'm displaying horizontal navigation like that [1]. Because
> > Navigation
> > > is
> > > > > actually list my background color is white. The question is how to
> > make
> > > > my
> > > > > navigation transparent component transparent? I know that I could
> > make
> > > > some
> > > > > css trick, but maybe you have a better solution.
> > > > >
> > > > >
> > > > each component use to have a css in Jewel and other one in JewelTheme
> > > (95%
> > > > of cases)
> > > > I still need to write some wiki for all of this
> > > > In the meanwhile, search for file "_navigation.sass". The one in
> Jewel
> > > has
> > > > definitions for beads and use to have some
> > > > standard css for things regarding "structure"
> > > > in the _navigation.sass in JewelTheme instead you'll not find almost
> > any
> > > > Royale bead, and css more related to colors, animations, fonts,
> sizes,
> > > > so more "theme" things that people would want to change.
> > > >
> > > > There you'll find
> > > >
> > > > // Navigation variables
> > > > .jewel.navigation
> > > > background-color: #ff
> > > >
> > > > So, you can do in many ways:
> > > >
> > > > 1) Create your own theme with the same structure as JewelTheme and
> just
> > > > change this navigation thing
> > > > 2) just do in your app in you css, since that will be
Re: Some questions about Jewel Navigation
Carlos,
I just looked into the problem with double call of change event. You are
using as default ListSingleSelectionMouseController - in navigation
component which is calling "change" event once someone is clicking on item.
However you are doing it again from ArrayListSelectionModel which probably
shouldn't happen. This model is calling only selectedItemChanged,
*selectedIndexChanged. *
I'm assuming you are calling "change" event in ArrayListSelectionModel
cause you wanted to know whether someone has changed selectedItem and
selectedIndex programmatically . If that was the case you should create a
bead which listening for events from model and react in specific way.
My proposition is:
1) Remove call of change event from Jewel ArrayListSelectionModel
2) Create a bead if you need for operation of programmatic change - in that
case do not use in parallel ListSingleSelectionMouseController
Thoughts ?
Thanks,
Piotr
wt., 11 gru 2018 o 22:13 Carlos Rovira napisał(a):
> Hi Piotr,
>
> but .nav will not do anything. As I write before the right things should be
>
> .jewel.navigation
> background-color: transparent
>
> This in you App css will win over the one in the theme.
>
> Didn't try, but that should work, at least is what I do when I want some
> quick change to try or something temporal, or even could be a final change
> too depending on the case.
>
>
> El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > I have tried to do point #2 from your options, but when I declare my own
> > class:
> >
> > .nav {
> > background-color: #ff
> > }
> >
> > It's being override by those one from framework. Maybe I have to
> inherited
> > from framework classes ?
> >
> > Thanks, Piotr
> >
> > wt., 11 gru 2018 o 20:44 Carlos Rovira
> > napisał(a):
> >
> > > Hi Piotr,
> > >
> > > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> > > piotrzarzyck...@gmail.com>) escribió:
> > >
> > > > Hi Carlos,
> > > >
> > > > I have started playing using Jewel lately more serious and have two
> > > > questions related to Jewel Navigation component.
> > > >
> > > > I'm displaying horizontal navigation like that [1]. Because
> Navigation
> > is
> > > > actually list my background color is white. The question is how to
> make
> > > my
> > > > navigation transparent component transparent? I know that I could
> make
> > > some
> > > > css trick, but maybe you have a better solution.
> > > >
> > > >
> > > each component use to have a css in Jewel and other one in JewelTheme
> > (95%
> > > of cases)
> > > I still need to write some wiki for all of this
> > > In the meanwhile, search for file "_navigation.sass". The one in Jewel
> > has
> > > definitions for beads and use to have some
> > > standard css for things regarding "structure"
> > > in the _navigation.sass in JewelTheme instead you'll not find almost
> any
> > > Royale bead, and css more related to colors, animations, fonts, sizes,
> > > so more "theme" things that people would want to change.
> > >
> > > There you'll find
> > >
> > > // Navigation variables
> > > .jewel.navigation
> > > background-color: #ff
> > >
> > > So, you can do in many ways:
> > >
> > > 1) Create your own theme with the same structure as JewelTheme and just
> > > change this navigation thing
> > > 2) just do in your app in you css, since that will be taken instead the
> > > JewelTheme
> > >
> > > Notice that this will change when we implement full dark mode, that
> > > navigation still doesn't support since
> > > that component was made after I make dark mode and still don't have
> that
> > > implemented in SASS so
> > > compiling SASS will generate a light/dark theme and/or flat/noflat
> theme
> > >
> > > Another question is - Did you notice that Navigation component fire
> > change
> > > > event two times - whenever you click on the item ?
> > > >
> > > >
> > > Thanks for reporting, I didn't notice, please feel free to fix that,
> just
> > > take into account that navigation renderer preventdefault to avoid
> trying
> > > to open a web page. I see this in the way google material solved
> > navigation
> > > things
> > > but maybe could be a better way to do it
> > >
> > > Thanks!
> > >
> > > Carlos
> > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
*
Re: Some questions about Jewel Navigation
Hi Piotr,
but .nav will not do anything. As I write before the right things should be
.jewel.navigation
background-color: transparent
This in you App css will win over the one in the theme.
Didn't try, but that should work, at least is what I do when I want some
quick change to try or something temporal, or even could be a final change
too depending on the case.
El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:
> I have tried to do point #2 from your options, but when I declare my own
> class:
>
> .nav {
> background-color: #ff
> }
>
> It's being override by those one from framework. Maybe I have to inherited
> from framework classes ?
>
> Thanks, Piotr
>
> wt., 11 gru 2018 o 20:44 Carlos Rovira
> napisał(a):
>
> > Hi Piotr,
> >
> > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> > piotrzarzyck...@gmail.com>) escribió:
> >
> > > Hi Carlos,
> > >
> > > I have started playing using Jewel lately more serious and have two
> > > questions related to Jewel Navigation component.
> > >
> > > I'm displaying horizontal navigation like that [1]. Because Navigation
> is
> > > actually list my background color is white. The question is how to make
> > my
> > > navigation transparent component transparent? I know that I could make
> > some
> > > css trick, but maybe you have a better solution.
> > >
> > >
> > each component use to have a css in Jewel and other one in JewelTheme
> (95%
> > of cases)
> > I still need to write some wiki for all of this
> > In the meanwhile, search for file "_navigation.sass". The one in Jewel
> has
> > definitions for beads and use to have some
> > standard css for things regarding "structure"
> > in the _navigation.sass in JewelTheme instead you'll not find almost any
> > Royale bead, and css more related to colors, animations, fonts, sizes,
> > so more "theme" things that people would want to change.
> >
> > There you'll find
> >
> > // Navigation variables
> > .jewel.navigation
> > background-color: #ff
> >
> > So, you can do in many ways:
> >
> > 1) Create your own theme with the same structure as JewelTheme and just
> > change this navigation thing
> > 2) just do in your app in you css, since that will be taken instead the
> > JewelTheme
> >
> > Notice that this will change when we implement full dark mode, that
> > navigation still doesn't support since
> > that component was made after I make dark mode and still don't have that
> > implemented in SASS so
> > compiling SASS will generate a light/dark theme and/or flat/noflat theme
> >
> > Another question is - Did you notice that Navigation component fire
> change
> > > event two times - whenever you click on the item ?
> > >
> > >
> > Thanks for reporting, I didn't notice, please feel free to fix that, just
> > take into account that navigation renderer preventdefault to avoid trying
> > to open a web page. I see this in the way google material solved
> navigation
> > things
> > but maybe could be a better way to do it
> >
> > Thanks!
> >
> > Carlos
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Some questions about Jewel Navigation
I have tried to do point #2 from your options, but when I declare my own
class:
.nav {
background-color: #ff
}
It's being override by those one from framework. Maybe I have to inherited
from framework classes ?
Thanks, Piotr
wt., 11 gru 2018 o 20:44 Carlos Rovira napisał(a):
> Hi Piotr,
>
> El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > Hi Carlos,
> >
> > I have started playing using Jewel lately more serious and have two
> > questions related to Jewel Navigation component.
> >
> > I'm displaying horizontal navigation like that [1]. Because Navigation is
> > actually list my background color is white. The question is how to make
> my
> > navigation transparent component transparent? I know that I could make
> some
> > css trick, but maybe you have a better solution.
> >
> >
> each component use to have a css in Jewel and other one in JewelTheme (95%
> of cases)
> I still need to write some wiki for all of this
> In the meanwhile, search for file "_navigation.sass". The one in Jewel has
> definitions for beads and use to have some
> standard css for things regarding "structure"
> in the _navigation.sass in JewelTheme instead you'll not find almost any
> Royale bead, and css more related to colors, animations, fonts, sizes,
> so more "theme" things that people would want to change.
>
> There you'll find
>
> // Navigation variables
> .jewel.navigation
> background-color: #ff
>
> So, you can do in many ways:
>
> 1) Create your own theme with the same structure as JewelTheme and just
> change this navigation thing
> 2) just do in your app in you css, since that will be taken instead the
> JewelTheme
>
> Notice that this will change when we implement full dark mode, that
> navigation still doesn't support since
> that component was made after I make dark mode and still don't have that
> implemented in SASS so
> compiling SASS will generate a light/dark theme and/or flat/noflat theme
>
> Another question is - Did you notice that Navigation component fire change
> > event two times - whenever you click on the item ?
> >
> >
> Thanks for reporting, I didn't notice, please feel free to fix that, just
> take into account that navigation renderer preventdefault to avoid trying
> to open a web page. I see this in the way google material solved navigation
> things
> but maybe could be a better way to do it
>
> Thanks!
>
> Carlos
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
*
Re: Some questions about Jewel Navigation
Hi Piotr, El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (< piotrzarzyck...@gmail.com>) escribió: > Hi Carlos, > > I have started playing using Jewel lately more serious and have two > questions related to Jewel Navigation component. > > I'm displaying horizontal navigation like that [1]. Because Navigation is > actually list my background color is white. The question is how to make my > navigation transparent component transparent? I know that I could make some > css trick, but maybe you have a better solution. > > each component use to have a css in Jewel and other one in JewelTheme (95% of cases) I still need to write some wiki for all of this In the meanwhile, search for file "_navigation.sass". The one in Jewel has definitions for beads and use to have some standard css for things regarding "structure" in the _navigation.sass in JewelTheme instead you'll not find almost any Royale bead, and css more related to colors, animations, fonts, sizes, so more "theme" things that people would want to change. There you'll find // Navigation variables .jewel.navigation background-color: #ff So, you can do in many ways: 1) Create your own theme with the same structure as JewelTheme and just change this navigation thing 2) just do in your app in you css, since that will be taken instead the JewelTheme Notice that this will change when we implement full dark mode, that navigation still doesn't support since that component was made after I make dark mode and still don't have that implemented in SASS so compiling SASS will generate a light/dark theme and/or flat/noflat theme Another question is - Did you notice that Navigation component fire change > event two times - whenever you click on the item ? > > Thanks for reporting, I didn't notice, please feel free to fix that, just take into account that navigation renderer preventdefault to avoid trying to open a web page. I see this in the way google material solved navigation things but maybe could be a better way to do it Thanks! Carlos -- Carlos Rovira http://about.me/carlosrovira
