Re: Routing (was Re: Spectrum Components)

What version of Basic does your project use? Could it still be a 0.9.7*? I think the dev branch is on 0.9.8-SNAPSHOT -Alex On 5/11/20, 5:37 AM, "Piotr Zarzycki" wrote: Hi Harbs, Today I have wiped out my cached Maven artifacts and tried build our application where I'm

Re: Routing (was Re: Spectrum Components)

Hi Harbs, Today I have wiped out my cached Maven artifacts and tried build our application where I'm using all stuff which you have lately added. I'm getting following type of issues and cannot build my project: Error: Type was not found or was not a compile-time constant: IRouter.

Re: Routing (was Re: Spectrum Components)

It should be fixed. > On Apr 21, 2020, at 2:47 PM, Harbs wrote: > > Yeah. I’ll fix that… > >> On Apr 21, 2020, at 10:59 AM, Piotr Zarzycki >> wrote: >> >> Hi Harbs, >> >> I see some properties which would no longer work [1] - If I use >> BrowserRouter as a host. In this specific class that

Re: Routing (was Re: Spectrum Components)

Yeah. I’ll fix that… > On Apr 21, 2020, at 10:59 AM, Piotr Zarzycki > wrote: > > Hi Harbs, > > I see some properties which would no longer work [1] - If I use > BrowserRouter as a host. In this specific class that property is not used, > but I'm pointing to the issue. Maybe HasRouter and

Re: Routing (was Re: Spectrum Components)

Hi Harbs, I see some properties which would no longer work [1] - If I use BrowserRouter as a host. In this specific class that property is not used, but I'm pointing to the issue. Maybe HasRouter and BrowserRouter should have some common interface ? [1]

Re: Routing (was Re: Spectrum Components)

Got it. It's working I'm able to get params. We will see what I can do more. :) Thank you! pon., 20 kwi 2020 o 17:51 Harbs napisał(a): > Exactly like lines 99 through 102 here: > > https://github.com/unhurdle/spectrum-royale/blob/master/SpectrumBrowser/src/view/BrowserRouter.mxml > < >

Re: Routing (was Re: Spectrum Components)

Exactly like lines 99 through 102 here: https://github.com/unhurdle/spectrum-royale/blob/master/SpectrumBrowser/src/view/BrowserRouter.mxml RouteToParameters will parse the parameters and use

Re: Routing (was Re: Spectrum Components)

Yeah I just realized that I didn't express myself clearly. I would ask differently cause you are saying about beads. What bead would parse for me those parameters ? https://myrul.com/test?target=somevalue=

Re: Routing (was Re: Spectrum Components)

Huh? Not sure what you’re asking. The parsing of the URLs are all done via beads. > On Apr 20, 2020, at 5:51 PM, Piotr Zarzycki wrote: > > I will check your changes, but looking into the code you didn't touch > parameter parsing. It probably will be the same story for BrowserRouter and >

Re: Routing (was Re: Spectrum Components)

I will check your changes, but looking into the code you didn't touch parameter parsing. It probably will be the same story for BrowserRouter and HasRouter - Maybe it's worth to place it in RouteToParameters ? pon., 20 kwi 2020 o 16:38 Harbs napisał(a): > I just pushed something. It builds,

Re: Routing (was Re: Spectrum Components)

I just pushed something. It builds, but I don’t have a setup to be able to test it properly. Calling setState() and renderState() should work, but I still haven’t finished beads to intercept links. Let me know how it goes… Harbs > On Apr 20, 2020, at 4:45 PM, Piotr Zarzycki wrote: > >

Re: Routing (was Re: Spectrum Components)

Harbs, Do you think you will have something pushed today/tomorrow or is it rather something for the next week or so ? pon., 20 kwi 2020 o 11:56 Piotr Zarzycki napisał(a): > Ok. Thanks I look forward to your update. > > pon., 20 kwi 2020 o 11:51 Harbs napisał(a): > >> I’m deprecating Router

Re: Routing (was Re: Spectrum Components)

Ok. Thanks I look forward to your update. pon., 20 kwi 2020 o 11:51 Harbs napisał(a): > I’m deprecating Router and replacing it with HashRouter and BrowserRouter. > > I’m going to try and keep the same beads working with either router. > > > On Apr 20, 2020, at 11:55 AM, Piotr Zarzycki >

Re: Routing (was Re: Spectrum Components)

I’m deprecating Router and replacing it with HashRouter and BrowserRouter. I’m going to try and keep the same beads working with either router. > On Apr 20, 2020, at 11:55 AM, Piotr Zarzycki > wrote: > > Harbs, > > What please describe what are you going to change exactly. Since I need to >

Re: Routing (was Re: Spectrum Components)

Harbs, What please describe what are you going to change exactly. Since I need to move forward with my feature in application I will probably implement adhoc solution with Router in app only, but I would like to avoid some big changes when you commit your code. Thanks, Piotr pon., 20 kwi 2020 o

Re: Routing (was Re: Spectrum Components)

There are beads which handle the following: 1. Paths — in a hash router, this would be the part of the url between the hash and the question mark or a second hash. In a “browser router” this would be the section between the base and and the question mark or a hash 2. Parameters — handles

Re: Routing (was Re: Spectrum Components)

Hi Piotr, I used hashes with params, so that's completely fine and we should have it. In fact, I think we already should have it since I'm seeing "RoutToParameter" class right? Maybe Harbs should confirm this since he implemented, and I just saw the class but still not use it. El dom., 19 abr.

Re: Routing (was Re: Spectrum Components)

I think there are apps that only use the hash, some that use only parameters, and some that will use both, so PAYG would not require the hash-only people to carry code for parameters and vice versa. -Alex On 4/19/20, 5:34 AM, "Piotr Zarzycki" wrote: Hi Alex, Could you elaborate

Re: Routing (was Re: Spectrum Components)

Harbs, Agreed with that. We can rename them, but even in case of HashRouter - does exclude it ability to have parameters ? Does those parameters not exists in HasRouter as well. Is it not a common stuff no matter what kind of url it is ? niedz., 19 kwi 2020 o 15:52 Harbs napisał(a): > After

Re: Routing (was Re: Spectrum Components)

It’s also interesting to see how Vue handles routing: https://github.com/vuejs/vue-router/tree/dev/examples > On Apr 19, 2020, at 4:27 PM, Harbs wrote: > > After thinking about this some more, I’m thinking that Router should be named >

Re: Routing (was Re: Spectrum Components)

Hi Harbs +1 that has more sense. Maybe actual Router should be renamed to HashRouter and create a new BrowserRouter. Since you created the first Router and Piotr is interested in applying to his work, would be possible for both to work on that? As I said, I'm fighting with other MD things but

Re: Routing (was Re: Spectrum Components)

After thinking about this some more, I’m thinking that Router should be named and we should add another type of router for standard path routing. React calls them HashRouter and BrowserRouter. Maybe we should use the same names…

Re: Routing (was Re: Spectrum Components)

Josh and Greg pointed into exactly the case which I have in our application. Urls are controlled by server sight and I cannot change it, so I rather need adjust how my application react towards different type of urls which could be used, rather create specific for some views. niedz., 19 kwi 2020

Re: Routing (was Re: Spectrum Components)

Hi Alex, Could you elaborate what do you mean exactly in that case saying PAYG? Parameter parsing should be done in different version of Router ? Thanks, Piotr pt., 17 kwi 2020 o 17:54 Alex Harui napisał(a): > Ideally, supporting the route information in parameters vs hash would be > done in

Re: Routing (was Re: Spectrum Components)

Hi Harbs, It sounds like you are asking me to check in onInit whether if(location.hash) exists then do something, but if doesn't exists check url params. - I may understand it in a wrong way, but I think location.hash may exists and location.search - where parameters are stored could exists

Re: Routing (was Re: Spectrum Components)

Hi Josh, many thanks for exposing this, I was not aware of that and I think that's very important for use Routing the right way. So for what I understand if user does not have server they need to rely on hashes, but if a server is available you can use full urls. I think we should abstract this

Re: Routing (was Re: Spectrum Components)

Thanks Josh, good to know. I think I got close to expressing that with 'the initial path needs to be handled by the server no matter what it is. It may not do anything different other than to serve the same content regardless of the path' But your example with .htaccess is a much more helpful

Re: Routing (was Re: Spectrum Components)

Yes, your understanding is correct. The HTML History API is not limited to the hash, and it can update other parts of the URL without reloading the whole page. However, if you are not using a hash, then your server may need some extra configuration to understand which URLs should be mapped to your

Re: Routing (was Re: Spectrum Components)

'AIUI, hash has to be used as the delimiter if you plan to change the route information within the application, otherwise the application will reload.' I am pretty sure that is no longer the case. HTML5 support for history changes it not like the old days and there is good native browser

Re: about current framework release (was Re: Routing (was Re: Spectrum Components))

Hi Alex, I'm just exposing that in the other repos there was various tries and reverts. I was expecting the same here. If you are getting enough progress to get the release in few hours, that's great. But maybe exposing you got all working to finish the release and send an email to the list will

Re: about current framework release (was Re: Routing (was Re: Spectrum Components))

Hi Carlos, First you are complaining that I was not making enough progress on the release. Then there have clearly been Release_Step emails this week and you are now claiming I did not give you enough warning? -Alex On 4/17/20, 9:38 AM, "Carlos Rovira" wrote: Hi Alex, a part

about current framework release (was Re: Routing (was Re: Spectrum Components))

Hi Alex, a part from the issue with version bumped, I thought that you were testing and changing, and this could be just a test as done in compiler. If this is the real release, great. But in that case, I think you should cherry pick my latest commit removing a class (scrollToIndex) since right

Re: Routing (was Re: Spectrum Components)

Ideally, supporting the route information in parameters vs hash would be done in a PAYG way. AIUI, hash has to be used as the delimiter if you plan to change the route information within the application, otherwise the application will reload. IOW, if the user is going to navigate in the

Re: Routing (was Re: Spectrum Components)

Whatever you think is fine by me. I don’t remember why I have "if(location.hash)”. It’s possible you can get rid of that conditional. It could be you can get rid of that and handle hashRecieved in a bead. If the hashReceived event has no hash you can then check the URL.You do need to make

Re: Routing (was Re: Spectrum Components)

Hi, that's the problem I was talking in the other thread. While a release process goes, we are stuck, for that reason I was proposing to do release from a branch, that is something totally legit and will make the rest of contributors free to continue work. As gitflow indicates, when release is

Re: Routing (was Re: Spectrum Components)

Thanks for input Carlos - I think I will have some scenario in future where Router may help me. I would update it with params once develop will be stable. Right now branch is switched to 0.9.8, so Alex probably is doing some work. pt., 17 kwi 2020 o 11:37 Carlos Rovira napisał(a): > Hi Piotr, >

Re: Routing (was Re: Spectrum Components)

Hi Piotr, I'm not saying is not right what you're doing. Just pointing that maybe for your use case adding all the Router sttuff is not worthit if you don't plan to make a real router use far beyond adding those params. But I think if there's some scenario not covered with passing params, we need

Re: Routing (was Re: Spectrum Components)

Hi Carlos, At some point you are right, but it was just really weird to me that Router has in state parameters property and it's empty. To me it looks like bug. I would be willing to set it properly in Router as Harbs suggested, but if you think it shouldn't be there - What would be the purpose

Re: Routing (was Re: Spectrum Components)

Hi Piotr, based on the url you provide, URLParameterBead seems the best option right? Or at least for the info you provided I don't see a SPA for now, just a need to load some params to set a state. If you need a full SPA, then is worth to add Routing and part of that could be receive params.

Re: Routing (was Re: Spectrum Components)

I think it would be better to have it here in Router. pt., 17 kwi 2020 o 09:37 Harbs napisał(a): > Alternatively, you can subclass Router to support setting the parameters > in the onInit method. > > Not sure which of these is best. > > > On Apr 17, 2020, at 10:35 AM, Harbs wrote: > > > >

Re: Routing (was Re: Spectrum Components)

I would like to make in RouteToParameters methods which handle events protected - Any objections to that ? pt., 17 kwi 2020 o 10:14 Piotr Zarzycki napisał(a): > Alex, > > I wanted to try out new stuff. I know about URLParameterBead, but I may > use also some other features available in Routing

Re: Routing (was Re: Spectrum Components)

Alex, I wanted to try out new stuff. I know about URLParameterBead, but I may use also some other features available in Routing itself. pt., 17 kwi 2020 o 10:02 Alex Harui napisał(a): > Could Piotr use URLParameterBead? > > On 4/17/20, 12:37 AM, "Harbs" wrote: > > Alternatively, you can

Re: Routing (was Re: Spectrum Components)

Could Piotr use URLParameterBead? On 4/17/20, 12:37 AM, "Harbs" wrote: Alternatively, you can subclass Router to support setting the parameters in the onInit method. Not sure which of these is best. > On Apr 17, 2020, at 10:35 AM, Harbs wrote: > > Actually,

Re: Routing (was Re: Spectrum Components)

Thanks for pointing it out. Do you suggest me to change framework code or your suggestion is something which I should rather do on my application ? pt., 17 kwi 2020 o 09:35 Harbs napisał(a): > Actually, it’s not going to work because the router.routeState.parameters > will not be set. > > You

Re: Routing (was Re: Spectrum Components)

Alternatively, you can subclass Router to support setting the parameters in the onInit method. Not sure which of these is best. > On Apr 17, 2020, at 10:35 AM, Harbs wrote: > > Actually, it’s not going to work because the router.routeState.parameters > will not be set. > > You will likely

Re: Routing (was Re: Spectrum Components)

Actually, it’s not going to work because the router.routeState.parameters will not be set. You will likely need to add code to set the router.routeState.parameters using the part of the location after the question mark. The easiest way to do that would be to either: 1. Modify

Re: Routing (was Re: Spectrum Components)

My url already have a proper look. I wanted to have it like that https://mydomain.com/somefolder/index.html?target=somevalue= somevalue pt., 17 kwi 2020 o 09:15 Alex Harui napisał(a): > What do you

Re: Routing (was Re: Spectrum Components)

I’m pretty sure it’ll work without the hash as well. Give it a try. > On Apr 17, 2020, at 10:23 AM, Piotr Zarzycki > wrote: > > Hi Harbs, > > Thanks for pointing me out, but this is still that Routing expects me to > use in url hashes - The question is - What if I can't use hashes, but url >

Re: Routing (was Re: Spectrum Components)

Hi Harbs, Thanks for pointing me out, but this is still that Routing expects me to use in url hashes - The question is - What if I can't use hashes, but url looks like I have presented in previous email ? Thanks, Piotr pt., 17 kwi 2020 o 09:20 Harbs napisał(a): > This app uses both path based

Re: Routing (was Re: Spectrum Components)

This app uses both path based and query based routing: https://unhurdle.github.io/spectrum-royale/#!asset?colorstop=dark You can see how it’s done here:

Re: Routing (was Re: Spectrum Components)

What do you want your URLs to look like? Remember that hash is used to keep the browser from reloading the app. On 4/17/20, 12:13 AM, "Piotr Zarzycki" wrote: I'm still looking into the code and it looks like Routing implemented now is not doing what I would expected. Everything is

Re: Routing (was Re: Spectrum Components)

I'm still looking into the code and it looks like Routing implemented now is not doing what I would expected. Everything is based on "hash" property in "location". Instead I need something which is in "search" of location. I will wait for your thoughts before I do try to handle stuff on my end.

Re: Routing (was Re: Spectrum Components)

Hi Guys, I really thought that I will be able to use Router [1] based on documentation and maybe eventually some look to the code [2] - to figure out how things should be implemented. However it looks like non of the existing stuff helps me to use in in real world application at all. I would like

Re: Routing (was Re: Spectrum Components)

Hi Harbs, thanks for taking a look, I'll try to apply your suggestions and see if I can make it work. If you plan to work in that new Routing implementation, I'll wait for it to write about it in blog and social media, since better to point people to the more elaborated one. I as well recommend

Re: Routing (was Re: Spectrum Components)

If we're dreaming of the future possible implementations, one vision is that the route paths are computed from the currentStates of Containers. That might have the least setup required, it would almost be automatic. IOW, Containers have both a label and currentState property. A routing

Re: Routing (was Re: Spectrum Components)

I’ve also been thinking about the router in general, and I came up with an idea on how to do it with beads. It’ll probably take me a few days until I implement the changes… In addition to , I think we can also offer which would allow different routers to be attached to different places in the

Re: Routing (was Re: Spectrum Components)

FWIW, I’d like to write a version of a router which allows for more declarative syntax for routing to components. Something like this: etc... > On Jan 21, 2020, at 11:20 PM, Harbs wrote: > > To see what I mean about href links, check out this page and click on a link: >

Re: Routing (was Re: Spectrum Components)

To see what I mean about href links, check out this page and click on a link: http://spectrum-royale/SpectrumBrowser/bin/js-debug/#!link Then use the side panel to navigate to the same pages. > On Jan 21, 2020, at 11:18 PM, Harbs

Re: Routing (was Re: Spectrum Components)

The problem is the href in the element in the nav. The hash is being changed to “#" after the router redirects. You need to handle routing in one of two ways (and not both). 1. Use setState() 2. Use href links To do #1, you need to remove the href from the elements (or use something else

Re: Routing (was Re: Spectrum Components)

Hi Harbs, this paste is the MainContent.mxml from TDJ with the changes I tried: https://paste.apache.org/ez6aq You can override whole file in your local and try to compile to see results. I'm sure you'll get the right way to work for your code. Thanks Carlos El mar., 21 ene. 2020 a las

Re: Routing (was Re: Spectrum Components)

Oops. I thought this email went out yesterday… I have very little time today. Can you show me the code you tried? > On Jan 20, 2020, at 8:01 PM, Carlos Rovira wrote: > > Hi Harbs, > > thanks for adding this. I think it will deserve some blog example, since is > something people requested in

Re: Routing (was Re: Spectrum Components)

Hi Harbs, do you have time to add Router to TDJ? Thanks El lun., 20 ene. 2020 a las 19:01, Carlos Rovira () escribió: > Hi Harbs, > > thanks for adding this. I think it will deserve some blog example, since > is something people requested in social media. > Can you please add it to Tour De

Re: Routing (was Re: Spectrum Components)

Hi Harbs, thanks for adding this. I think it will deserve some blog example, since is something people requested in social media. Can you please add it to Tour De Jewel? I tried but, I get two problems: 1.- back/forth buttons are not working 2.- previous button seems to register more than once

Re: Routing (was Re: Spectrum Components)

I don’t remember how deep linking worked, but the concept is similar. Routing is the modern term. FWIW, here’s an article on routing strategies vis a vis url paths: https://codecraft.tv/courses/angular/routing/routing-strategies/

Re: Routing (was Re: Spectrum Components)

Thanks for this. In what way is this different from deep linking in Flex, apart from the name? On Mon, Jan 20, 2020 at 8:30 AM Harbs wrote: > Not sure what you’re looking for. I tried to document the class as best as > I could: > >