On 2021-10-11 15:36 , Bob Brown wrote:
> I have read the doco section: “7.2.2. Navigator factory” is this the way
> to go? Provide an extension of Navigator?
>
> I like that the doco says “..get in touch via the mailing list if you need
> help.”
>
>
>
> Here I am 😊
>
>
LOL
The doco does say “While not as crosscutting as using a custom navigator
> factory it’s also possible to decorate navigators with additional methods
> by creating modules based on them.”
>
> So maybe:
>
> final form = $('form').module(MyModuleWithMethodsDefined)
Yes, this would be my preference - use a module to decorate a navigator.
The biggest benefit in my eyes is that IntelliJ is able to infer types
correctly and you get autocompletion/navigation to the implementation for
methods added this way while adding them via meta classes or custom
navigator factory makes everything dynamic and opaque to IntelliJ thus
significantly hindering authoring of your Geb code. Custom navigator
factories are a mechanism for this predating addition of Navigator.module()
method (in https://github.com/geb/issues/issues/311) which allows to create
instances of modules anywhere and not just in content blocks of other
modules and pages as it was the case before. That in turn made it much
simpler and concise to decorate a navigator instance with methods defined
on a module.
On Tue, Oct 12, 2021 at 9:15 AM Bob Brown <[email protected]> wrote:
> I ASSUME(/hope) that this is more ‘performant’ than the metaClass-hacking
> that I did before(…?)
>
> It’s a bit cleaner code, so that’s a ‘win’, regardless…
>
I'm not sure it's that much more "performant" but it wouldn't be me
immediate concern. It's definitely cleaner and easier to understand code.
And as I said, there are benefits to authoring code using such methods if
they are added that way.
>
>
> The one ‘wrinkle’ I found: if I used ‘browser.report’ within
> FlowFormDecoratorModule, it produced different results to when I used
> ‘report’ from within withFlowViewForm.
>
>
>
> This may have something to do with the fact that I am also using
> geb-spock-reports.
>
>
>
> Outside the module (directly within withFlowViewForm for example) I would
> end up with a PNG image named very specifically, and based on more than
> just the report parameter value like:
> 001-002-EXXXXX__Cold_Water__Reason_For_Call__Normal_Path-fred.png.
>
>
>
> Within the module, I couldn’t just call ‘report’ and if I called
> “browser.report ‘fred’”, I would simply get ‘fred.PNG (which didn’t play
> well with geb-spock-reports).
>
>
>
> That’s why I pass a ‘report’ closure as parameter to the module: it lets
> me use the ‘good’ report instance…
>
This is because outside of the module you are not calling Browser.report(),
you are actually calling GebReportingSpec.report() which prepends the
report name with some counters and the name of the current test. If you're
on Geb 5 then you could pass testManager to your module and call report()
on that - testManager is an instance of geb.test.GebTestManager and
GebReportingSpec actually delegates the report() method to it.
>
>
> Thanks to J. David Beutel for planting the seed…
>
And thanks to you for reading the docs - quite a lot of effort went into
them over the years and it goods to see people making use of them!
Marcin
--
You received this message because you are subscribed to the Google Groups "Geb
User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/geb-user/CA%2B52dQRvzbPW5RFB9zm4Q7eB60jDbVuy3m9vPQi5QJRVd2zHaA%40mail.gmail.com.
