Hi Carlos
>probably Container is not a good parent of that component. >A Container is suited for "unknown additions of other components". But it >seems ECharts >manages its own data and the component will not add anything (from a Royale >point of view) >that is not known. I'm guessing that a EChartComponent is able to render just >one chart. >Maybe I'm wrong. We need a simple container that allows content wrapping, maybe HGroup? >I think most of the things you exposed can be managed by having a component >API that will bring the >data to the set of beads created for that component. I can't do much more >since I still couldn't take the >time to investigate ECharts and don't know the internals, but I figure things >probably can be managed >that way. For that reason when we talked about creating a library in Royale I >was proposing more a > UIBase (based) component than just @externs, or create one library for > @externs and then another one > that uses it that creates the Royale component and its beads. hahaha, HOW GOOD THAT SOUNDS! I will do it in a second phase. But all these work you're doing is very good since it's the only way to learn how things should be done. > Probably your first component will not be "accurate", but do the work and you > learn in the process of > creating good quality Royale components. But the process is that, and require > time and effort to investigate > and to get each day better code and solutions. That is what I say too ... "it is not wasting time", it is learning, for me all happiness and joy š , the truth is that I am passionate about this world ... the pity is that I did not have the adequate base of studies , but I put it all! I will continue later. Thank you. Hiedra. El miĆ©., 2 sept. 2020 a las 0:12, Maria Jose Esteve (<[email protected]<mailto:[email protected]>>) escribiĆ³: > You have already answered Carlos, Crux is not suitable for a library > (I was imagining it ... but I thought it could be a good opportunity > to put it to the test and change the paradigm that we usually use in > the creation of > controls) > I am "still" with the ECharts implementation. Apart from the base > class, @externs, I have created a component that extends Container to > make the mxml implementation easier and a bead to add "Themes" support. > > The themes, whether they are predefined (they exist in the themes / > json / xxx.json folder) or custom (they are defined locally and are > kept locally) cannot be used directly, first they must be "loaded", > then they must be registered (in the global class ) and, only then, > can they be assigned to one or more charts. We can only assign a Theme > in the initialization of the chart instance, which means that if we > have an instantiated chart, the current instance will be eliminated > and a new one will be created. This is not a problem because it is > managed by the js echarts script BUT I am trying that, in the case > that a chart has an "Initial topic", the installation is not initialized > until this initial topic is "registered" > and operational. > To load the predefined Themes (templates) I started by creating a > static class that contained a URLLoader that I called from any bead > (it configured the loadcomplete listeners ...), and where it > controlled the concurrency of the load calls (all graphics they try to > load their theme before > initializing) but I found it to be very "dirty" and messy. (I think > I'll go back to this version) > > Another point that remains off the hook is the load cycle. > If we create the chart from code, like this, everything is controlled > by us and there is no hitch, but when we insert the components in an > unattended way, in mxml tags, things get complicated. (At this point I > think it would be good to implement some "loading states") > > I'm going to go back and see if tonight I can have something "that works" > > Thanks for everything. > > Hiedra. > > -----Mensaje original----- > De: Carlos Rovira <[email protected]<mailto:[email protected]>> > Enviado el: martes, 1 de > septiembre de 2020 20:36 > Para: Apache Royale Development > <[email protected]<mailto:[email protected]>> > Asunto: Re: Crux - Inject model in Bead > > Hi Maria Jose, > > Can you provide info about what you're trying to do? Maybe that way I > can give you some suggestions. > > About your question. I don't know what the library is about, but > usually Crux is a microframework used in applications, not libraries > to glue different parts and make models and other components > accessible globally through all the application's code. > > A part of an app model is a typical case(i.e: You want to load a user > in a module and store in a model and then retrieve info of that user > in another module or in the app shell). But a library used to give us > components that have its own beads (model, controller, view,...) and the > scope is "local" > to that component, so Crux usually is not something to be applied at > that level. > > So your library is about "global scoped" or is "local scoped"? Usually > use Crux only if it is the first case. > > > El mar., 1 sept. 2020 a las 18:46, Maria Jose Esteve > (<[email protected]<mailto:[email protected]>>) > escribiĆ³: > > > Thanks Carlos, > > I don't know what to do, I'm lost: P. Since last week I have done > > nothing but model "what I had" with crux and now ... > > The main problem is that I do not know the actual operation of Crux, > > nor what it means ... > > I'm going to look at the projects in the crux example sdk again to > > see if I see any other alternatives. > > I take the liberty of asking you another question, directly ... > > In the case of the small library, which I am building, could I > > implement the Crux configuration if I don't have any initial mxml? > > Maybe it's a silly question, I'm sorry if that's the case. In the > > library I have a main class, and I wanted to include all the other > > components (classes, interfaces, events, etc ...). Is it feasible? > > > > Thx. > > Hiedra. > > > > -----Mensaje original----- > > De: Carlos Rovira <[email protected]<mailto:[email protected]>> > > Enviado el: martes, 1 de > > septiembre de 2020 16:55 > > Para: Apache Royale Development > > <[email protected]<mailto:[email protected]>> > > Asunto: Re: Crux - Inject model in Bead > > > > Hi Maria Jose, > > > > you can inject views since they are processed by Crux to do so. Remember: > > > > <crux:CruxConfig viewPackages="jewel.todomvc.views.*" ... > > > > the same we add eventPackages too. > > > > But a bead is not a view, so it's not processed. Maybe a "BeadProcessor" > > would be handy here ;-) > > but still doesn't exist. maybe could be a good addition for Royale > > Crux version but we'll need to measure how that should be done. > > > > I think other ways could be available like maybe implementing > "ICruxAware" > > interface. > > I remember using it in Flex (Swiz) times, but never tried it in > > Royale with Crux, so can't say if that was migrated completely and > > if it is working. I think that is "unexplored realms" for you to test. > > > > > > > > El mar., 1 sept. 2020 a las 14:01, Maria Jose Esteve > > (<[email protected]<mailto:[email protected]>>) > > escribiĆ³: > > > > > Hi, > > > I am implementing crux. I inject the model perfectly into any view > > > and / or controller but I can't inject it into a Bead. How should > > > I do > it? > > > If I inject the model into the main control, and retrieve it from > > > the Bead as << (_strand as EChartsComponent) .echartsThemesModel > > > >> I can > > use it. > > > I imagine that this will have a technical explanation, which > > > escapes me, ... > > > If someone could help me ... > > > > > > Thank you > > > Hiedra > > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > > > > -- > Carlos Rovira > http://about.me/carlosrovira > -- Carlos Rovira http://about.me/carlosrovira
