Going back to this programmatic configuration topic, I agree with Ralph's
idea of using Configuration/Node. Thus, a programmatic API would likely
work via that idea so as not to cause problems with this sort of annotation.
On 9 July 2014 14:34, Ralph Goers wrote:
> Not necessarily Groovy specifi
Not necessarily Groovy specifically, but in general, yes. However, even then
it might be nicer to have a layer above that that creates the Nodes and adds
them to the hierarchy. I’m not really sure what that would look like. I’d have
to try to build something before I would know what would be “
A Groovy DSL using closures would make a neat interface to creating the
Node hierarchy you're speaking of. Is that what you meant when you
mentioned this in the past?
On 9 July 2014 01:03, Ralph Goers wrote:
> IMO the proper, and recommended, way to do programmatic configuration is
> to impleme
IMO the proper, and recommended, way to do programmatic configuration is to
implement a Configuration, the end result of which is a tree of Nodes. Doing
that leverages everything we have to offer and is probably simpler to implement
in the end. We should create a sample that shows how to do th
Actually, if the framework detects a "required" violation and logs a
message, it should not call the create() method, so there would no double
logging.
It would then be up to the plugin author to decide what level of validation
he or she wants:
- Use the required annotation attribute and let the
That is why programs that do programmatic configuration should use an API and
not call the components directly
Sent from my iPad
> On Jul 8, 2014, at 6:56 PM, Gary Gregory wrote:
>
> Hm... if the error logging takes place in the plugin framework, then it
> should be removed from the create()
Crap, that does actually make things more complicated! It's almost getting
to the point where bytecode manipulation is starting to sound like a decent
idea at times.
On 8 July 2014 20:56, Gary Gregory wrote:
> Hm... if the error logging takes place in the plugin framework, then it
> should be r
Hm... if the error logging takes place in the plugin framework, then it
should be removed from the create() methods, but then apps that do
programmatic configuration will not benefit from the error logging. We
would then need to either keep the current guard clauses (with no logging)
or remove the
I support this. Should be added to @PluginAttribute and
@PluginBuilderAttribute or whatever it's called.
On 7 July 2014 11:06, Ralph Goers wrote:
> Seems reasonable to me.
>
> Ralph
>
> On Jul 7, 2014, at 8:35 AM, Gary Gregory wrote:
>
> Why don't we have a required flag?
>
> Using it and thro
Seems reasonable to me.
Ralph
On Jul 7, 2014, at 8:35 AM, Gary Gregory wrote:
> Why don't we have a required flag?
>
> Using it and throwing an Exception when this condition is violated would
> avoid guard code like:
>
> @PluginFactory
> public static RegexFilter createFilter(
>
10 matches
Mail list logo
