Welcome the channel on the development of Cro, a set of libraries for building reactive distributed systems, lovingly crafted to take advantage of all the Raku Programming Language has to offer (cro.services). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
06:40 patrickb joined 07:00 patrickb left 09:43 Xliff joined
Xliff Hello. 09:43
Once again I am dusting off my work with Cro::WebApp. 09:44
This time I'd like to look into the possibility of making the route{} block pluggable.
Has someone experimented with a way to make the route block accept input from different locations (ala Route:: modules) 09:45
If so, is there a blog post or write-up describing how this can be done?
Thanks.
Is there a mechanism for assigning a prefix for a set of routes? 09:47
Something like "route { prefix 'prefix' { get -> 'endpoint' { ... }; }; }; 09:48
Would then have one endpoint served by GET request to 'prefix/endpoint' 09:49
Will this work as expected if the object attributes match the form field names? 10:27
...
gist.github.com/Xliff/ceb6f6a50935...82173eef21 10:30
jnthnwrthngtn Xliff: The prefix is just `include 'prefix' => route { get -> 'endpoint' { } }` 10:41
If you have a method on Instance to coerce it from a Hash, then probably `get -> Instance() $i { }` would do the job. 10:43
I'd wondered about having some object unpacking stuff in Cro but nowadays figure it's probably better to just leave it to coercions. 10:44
Xliff How would the coercion method on Instance work?
method Instance (%hash) { ... }
jnthnwrthngtn: Thanks for the information on 'include' 10:45
Have you thought about making that "Pluggable"
For example, can include take data from a flatted (or unflattened) hash?
10:47 sena_kun joined
jnthnwrthngtn Just write a `method COERCE(%hash) { }` on Instance 10:47
include is slurpy iirc
There's a further plugin mechanism in HEAD (release planned later this week) that lets you stash and obtain state relating to the current route blcok 10:48
Xliff HAH! Didn't know about COERCE()
I've always been handling it from the other direction...
jnthnwrthngtn Note that since `request` and `response` are dynamically scoped a lot of "plugin" things don't even *need* an explicit mechanism; you just write subs. `web-socket` works that way for example.
But for things like `template` where we wanted to have configuration associated with the route block and find it (accounting for `include`s), there's a new mechanism now 10:49
Xliff Looking forward to your writeup on these new features, then. 10:50
jnthnwrthngtn There's already doc comments explaining it in the source; we're working on getting all of those extracted and available online also, for those who don't use Comma and thus can't enjoy the docs view in that. :) 10:51
So far as plugin-y stuff in general goes: I'm being careful what is introduced, since the longer-term plan is for `route` to become a macro and to analyze/compile the routing at compile time 10:52
Along with being able to look at `request-body` and signatures etc. to produce an autoamtic OpenAPI spec from the `route` block, so one can write Raku and get the sepc for free.
Xliff nice! 10:53
How long after the release of RakuAST will it be before we get macros?
p6-GLib et all want to play... # :) 10:54
Passed 600kloc of that, BTW
jnthnwrthngtn Probably not long at all for something to play with, as with all these things a bit longer for maturity
11:02 Xliff left 12:05 Xliff joined
Xliff . 12:05
jnthnwrthngtn: Ouch. You are not logging this channel? 12:06
Oh, you are. Is there a web interface?
sena_kun Xliff, logs.liz.nl/cro/live.html <- ? 12:08
Xliff Oh, hey! Powered by Cro. Nice! 12:40
lizmat Xliff: just wait when we're done with the styling (in cooperation with sena_kun :-) 13:27
Xliff lizmat: Noticed that. Clicking the "scroll down" link results in unstyled output 13:33
Is there more work to pass around?
lizmat Xliff: possibly, after I get this first version out according to my liking :-) 13:53
Xliff :)
lizmat: If you want to wrap a function with a given argument, would that look something like this: $method.wrap(&wrapper).assuming($always-first-param) 13:54
lizmat tbh, I would have to check :-) 13:55
never used .assuming myself
if you look at the *current* underlying code, you understand why :-)
Xliff Me neither.
But then a light bulb started flickering, and I thought... "oh maybe".... 13:56
17:16 sena_kun left 20:15 SmokeMachine_ left 20:42 SmokeMachine_ joined
Xliff This is a bit confusing: Method 'resolve' must be implemented by Cro::WebApp::Template::Repository because it is required by roles: Cro::WebApp::Template::Repository 21:02
Should I bug this? 21:03
jnthnwrthngtn Depends, how did you make it happen? 21:15
If in normal Cro usage, then it's odd and yes, report it. 21:16
If you were trying to make a custom template repository, sounds like you punned the role (perhaps `is` instead of `does`)?
Xliff Cro::WebApp::Template::Repository.new? 21:21
That would be a role, wouldn't it?
If I wan to compile a template, should I pass an instance or a type to :$repository when using Cro::WebAp::Template::Compiled.new()? 21:22
japhb Roles can directly instantiate -- so if you .new a role directly, it auto-puns to a class containing just that role. 21:23
(Apologies if I misunderstood the question, BTW. Can't tell if that's what you were asking.) 21:24
jnthnwrthngtn Yeah, that `.new` is to blame; you can't .new a role with unimplemented methods.
You're not really meant to instantiate Cro::WebApp::Template::Compiled yourself; you implement Cro::WebApp::Template::Repository and then give your instance to set-template-repository 21:26
load-template does the creation of the Cro::WebApp::Template::Compiled 21:27
Xliff When you say "Implement Cro::WebApp::Template::Repository" you are taling about implementing a class that does and satisfies the role, correct?
jnthnwrthngtn Yes
Xliff Ok, thanks!
I'll have to see what all that entails.
jnthnwrthngtn Like github.com/croservices/cro-webapp/...ry.pm6#L54 for example
What're you aiming at achieving, btw?
We only just starting pondering which pieces we want to make extensible API here, and we're only so imaginative (we've handled templates from the filesystem and from resources, and figure maybe somebody will want to have them pulled from a database at some point...) 21:29
Xliff Outputting string-based cro templates. I have no need for files.
This a first step from then moving to templates stored in a database.\ 21:30
jnthnwrthngtn oh, then maybe the path of least resistence is IO::String and passing that to `load-template`
Xliff If you have suggestions as to better implement that, please let me know.
Ah, yes. Um. IO::String?
jnthnwrthngtn I think that's what the module is called. Make a string be like an IO handle. 21:31
Xliff github.com/zostay/raku-io-string
jnthnwrthngtn oh, maybe I'm confused and it only does the other direction? I thought it did string to IO handle also 21:32
Sigh, surely somebody did a module for this :)
Though of course maybe Cro::WebApp should just have a function for this, to avoid the workaround
Xliff Yeah, I think it works by something like $buffer = IO::String; $buffer.print: "This is wat should be in the buffer"; and the using $buffer in the placed where an IO::Handle should go. 21:33
??
I always wondered why there was no Str() based load-template 21:34
jnthnwrthngtn I couldn't imagine somebody wanting to have them in the database, I guess. 21:37
Probably because I can't imagine working on them without highlighting, auto-complete, reference resolution, etc. :D 21:38
japhb jnthnwrthngtn: When you invest heavily in the hammer ....
jnthnwrthngtn But yeah, just 'cus I wouldn't do something isn't a reason for it to be impossible. :) We should add a candidate taking a Str also.
Can sneak it in ahead of tomorrow's (probably) release, I guess. 21:39
Though I've gotta be afk for a bit now 21:40
japhb Yay!
japhb is always happy to hear about new Cro releases. :-)
Xliff Thank you, jnthnwrthngtn 22:00
!

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!