Dynamic components

[Mario Giammarco]

Hello,

I have this use case: a select widget called "filter by" and a widget that can be a text input or date input or numeric input depending on choice made on select widget.

Is it possible to do with Nowicket?

Thanks,

Mario

[Edwin Stang]

Hi Mario,

yes you can do that. The simplest idea is to define a panel that contains all the widgets you want to have support for. Then make them visible/invisible depending on the data being displayed. You could even do this with a NoWicket model that handles the logic and different constructors or factories that instantiate the model according to the data to be displayed. Though if you want it to be a bit more dynamic, you could replace the component for displaying during runtime inside a plain Wicket panel (non NoWicket, only the components themselves can be NoWicket generated, though the holding panel should rather be a plain Wicket one). The replacement can be done via a Wicket Behavior. For our cases we were normally fine with the first, simple idea since we had a finite amount of possible components to switch between. In your case it seems this could be applied here too. If you have further questions on how to actually do this, feel free to ask. I could even create a sample for this use-case if neccessary.

Best regards,
Edwin

[Mario Giammarco]

I am trying with basic: I will read again documentation but I have tried to change the model of another widget with this code:

public void setOperatore(final Operatore operatore) {

        setValore("foo");

        this.operatore = operatore;

    }

Where Operatore is an enum and valore is a String.

I hoped that changing value in Operatore select widget will change the other widget but it seems it happens only when you trigger the change in a button.

[Edwin Stang]

This is the case, because the NoWicket button callback invokes "GuiService.get().processRequestFinally(getComponent());" after processing the event. You can invoke the same method inside your own behavior/event handler to update the UI. The only restriction is that it has to be called inside a Wicket request life cycle call since the page needs to be available (so it is not possible to call this method to push content from outside of a wicket thread). Alternatively you can manually update the components via the normal wicket mechanisms. Though you won't get gui service tasks executed like showModalPanel or showStatusMessage is you don't call "GuiService.get().processRequestFinally(getComponent());". The GuiService method handles the GuiService tasks and just updates all forms to push the contents to the client browser.

An example for a Behavior can be found here: https://github.com/subes/invesdwin-nowicket/blob/33d8394a0e01b808509a53e86721f0ff0d82684f/invesdwin-nowicket-parent/invesdwin-nowicket/src/main/java/de/invesdwin/nowicket/generated/binding/processor/visitor/builder/component/ModelAjaxFormSubmitBehavior.java

[Mario Giammarco]

Thanks for suggestions I will try them for sure.

Meanwhile I am evaluating several frameworks/approaches for User Interface generation.

If you look at elm language or React framework you see that there is a model (like NoWicket one). Apps modify only the model and the view got updated (the only new thing here is an intelligent algorithm that makes a new dom with only diffs from previous dom to speed up things). Even if Nowicket is object oriented and elm is functional they are very similar. I dare to se that if in each setter of the model the GuiService.get().processRequestFinally(getComponent()); is executed you obtain the same behaviour of elm/react with Nowicket.

But I do not know it calling always that method can slow down wicket too much.

[Mario Giammarco]

Regarding this I am looking at AjaxChoice example. Here it seems @Eager annotation is used to obtain the same result is it possible?

[sub es]

The GuiService method should be only called once per request. Though it only marks the components for wicket so they get updated on the client browser. You don't have to call this method in the setters (the models don't know the components/widgets/pages and should not know them). Any NoWicket button/behavior will automatically call the aforementioned GuiService method for you automatically. Only when you use custom behaviors/event handlers in plain wicket, you have to hook them into NoWicket with the given GuiService method.

I guess React is javascript based instead of java, that is a big architectural difference I guess.

--
You received this message because you are subscribed to the Google Groups "invesdwin-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to invesdwin-platf...@googlegroups.com.
To post to this group, send email to invesdwin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/invesdwin-platform/9c4b875d-a4eb-4acb-828d-e111401de84a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sub es]

Yes, eager is used to immediately invoke an event on changes. It will then also call the given GuiService method automatically for you and push all changes you made to the client browser. A nice benefit is that is also handles the validation logic for you and is the preferred way of eagerly updating information when the NoWicket models are involved. I guessed that your use case was coming from a custom behavior, so I did not think about the obvious way of using the eager annotation. Sry :D

Von: mgiam...@gmail.com Gesendet: 28. Dezember 2017 7:38 nachm. An: invesdwin...@googlegroups.com Betreff: Re: Dynamic components

--

You received this message because you are subscribed to the Google Groups "invesdwin-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to invesdwin-platf...@googlegroups.com.
To post to this group, send email to invesdwin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/invesdwin-platform/ee18048f-d6ca-42ca-9f9b-55a2e127fdef%40googlegroups.com.

[Mario Giammarco]

Il giorno giovedì 28 dicembre 2017 20:15:34 UTC+1, subes ha scritto:

I guess React is javascript based instead of java, that is a big architectural difference I guess.

I am comparing them at a very high altitude. A more pratical problem of elm and react is that they do not have a widghet component library (as far as I know).

 

To unsubscribe from this group and stop receiving emails from it, send an email to invesdwin-platform+unsub...@googlegroups.com.

[Mario Giammarco]

I have tried with making widgets visible/invisible. It works but it makes validation difficult and code is less readable.

I do not understand the second idea about constructors/factories.

I have tried another approach: I thought that I can use subclassing:

public Bar1 extends AbstractFoo {

  private String attribute1;

....

}

public Bar2 extends AbstractFoo {

  private Date attribute2;

...

}

And in the page model:

public AbstractFoo getFoo() {

  if (condition) return new bar2();

  else return new Bar2();

}

But it seems your framework does not render abstract classes.

Or am I doing something wrong?

Thanks again,

Mario

Il giorno mercoledì 27 dicembre 2017 21:47:43 UTC+1, Edwin Stang ha scritto:

[Edwin Stang]

Each implementation needs its own panel+html. The abstract class can only contain parent html that is included in the child as normal with wicket components.

The idea with the constructor/factory is the following:

Image the model:

---------------------
public class SomeModel{
private String strValue;
private Integer intValue;

SomeModel(String strValue){
this.strValue = strValue;
this.intValue = null;
}

SomeModel(Integer intValue){
this.strValue = null;
this.intValue = intValue;
}

public boolean hideStrValue(){
return strValue == null;
}

public boolean hideIntValue(){
return intValue == null;
}

@Title("Value")
public String getStrValue(){
return strValue;
}

@Title("Value")
public Integer getIntValue(){
return intValue;
}

public void setStrValue(Integer strValue){
this.strValue = strValue;
}

public void setIntValue(Integer intValue){
this.intValue = intValue;
}
}
---------------------------

This will use the same model for all different value types. The HTML generator will generate a component for each property. This just needs to be aligned via bootstrap so that when the others get hidden, it appears as if only that specific visible component was supposed to be there. For this you can either put all components into the same grid column or just make the whole grid column of each component invisible with the component itself. This can be done with wicket:fragment (https://wicket.apache.org/learn/examples/usingfragments.html) and/or wicket:enclosure (https://cwiki.apache.org/confluence/display/WICKET/Wicket%27s+XHTML+tags#Wicket'sXHTMLtags-Elementwicket:enclosure). You can wrap this widget into a custom panel to embed it in a more complex model as a reusable widget.

[Edwin Stang]

Regarding your idea of using abstract classes, the following link provides documentation about how to use wicket:extend and wicket:child properly: https://wicket.apache.org/learn/examples/markupinheritance.html

Since both approaches work and you want a specific one, you can create a sample project that demonstrates what you are doing exactly, then I could create a pull request for what needs to be done to actually make it work.

[Mario Giammarco]

Il giorno martedì 2 gennaio 2018 19:26:59 UTC+1, Edwin Stang ha scritto:

Each implementation needs its own panel+html. The abstract class can only contain parent html that is included in the child as normal with wicket components.

Probably I do not understand. Please note that:

1) I try obviously to hide Wicket as much as possible

2) if I do this:

public Bar1() { return new Bar1(); }

Your html code generator correctly generates html to render widget. Only if I return an abstract class it generates nothing.

 

The idea with the constructor/factory is the following:

Nice, but can you do a static validation of model below?

[Mario Giammarco]

Il giorno martedì 2 gennaio 2018 19:30:55 UTC+1, Edwin Stang ha scritto:

Regarding your idea of using abstract classes, the following link provides documentation about how to use wicket:extend and wicket:child properly: https://wicket.apache.org/learn/examples/markupinheritance.html

Since both approaches work and you want a specific one, you can create a sample project that demonstrates what you are doing exactly, then I could create a pull request for what needs to be done to actually make it work.

Thanks for help, I have not finished to build the sample project, anyway it will be like this: an enum generates an @Eager select to do some searches on a db. Depending on what  you ask to search some fields will appear and you have to fill them. If validation passes a rest web service will be called with all data in input. 

The most elegant/object oriented way to do it is this: 

1) an abstract class "search". Some concrete  model classes that defines various types of sesarch possible

2) an enum with search types ("by name", "by date" and so on). In the enum I put in each value the corresponding class (BynameModel.class).

3) in the @Eager setSearchType (SearchEnum s) I set also the model to show

4) I show the model

5) when the user press send in the void send() I call the getJson from concrete model class (polimorph call)

[Edwin Stang]

Hi Mario,

thanks for the clarification. I guess code speaks more clearly, so I created a sample that should demonstrate both the simple approach and the inheritance/factory/constructor approach.

See the code here:
https://github.com/subes/invesdwin-nowicket/tree/master/invesdwin-nowicket-parent/invesdwin-nowicket-examples/invesdwin-nowicket-examples-guide/src/main/java/de/invesdwin/nowicket/examples/guide/page/wicket/dynamiceditorfields

Or try the sample live here:
http://invesdwin.de/nowicket/dynamiceditorfields

With a bit better bootstrap formatting you can get a nice search form with this approach. Use the simple approach for simple/dynamic cases and the inheritance approach for more complex cases. Though making the inheritance approach change types dynamically requires an additional example if you desire that.

While implementing it I found some bugs related to dynamically making a component visible again after it became invisible. Please update your snapshots to get the fixes.

Best regards,
Edwin

[Mario Giammarco]

Thank you very very much for your code example.

Now I understand my fault, in the superclass or in the interface there must be the getter for a generic Object of the value!

Then all is automatic.

[Mario Giammarco]

Regarding this way please make clear in documentation that static validation is not applied if a field is hidden. 

Il giorno mercoledì 27 dicembre 2017 21:47:43 UTC+1, Edwin Stang ha scritto:

[sub es]

What do you mean by static validation? You mean bean validation of the model?

Von: mgiam...@gmail.com Gesendet: 3. Januar 2018 12:29 nachm. An: invesdwin...@googlegroups.com Betreff: Re: Dynamic components

--

You received this message because you are subscribed to the Google Groups "invesdwin-platform" group.

To unsubscribe from this group and stop receiving emails from it, send an email to invesdwin-platf...@googlegroups.com.

To post to this group, send email to invesdwin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/invesdwin-platform/771508ba-53eb-45cc-bf92-101abcc7c4be%40googlegroups.com.

[Mario Giammarco]

Yes, what in your documentation you call "static validation" :-)

Il giorno mercoledì 3 gennaio 2018 12:35:44 UTC+1, subes ha scritto:

What do you mean by static validation? You mean bean validation of the model?

Von: mgiam...@gmail.com Gesendet: 3. Januar 2018 12:29 nachm. An: invesdwin...@googlegroups.com Betreff: Re: Dynamic components

Regarding this way please make clear in documentation that static validation is not applied if a field is hidden. 

Il giorno mercoledì 27 dicembre 2017 21:47:43 UTC+1, Edwin Stang ha scritto:

Hi Mario,

yes you can do that. The simplest idea is to define a panel that contains all the widgets you want to have support for. Then make them visible/invisible depending on the data being displayed. You could even do this with a NoWicket model that handles the logic and different constructors or factories that instantiate the model according to the data to be displayed. Though if you want it to be a bit more dynamic, you could replace the component for displaying during runtime inside a plain Wicket panel (non NoWicket, only the components themselves can be NoWicket generated, though the holding panel should rather be a plain Wicket one). The replacement can be done via a Wicket Behavior. For our cases we were normally fine with the first, simple idea since we had a finite amount of possible components to switch between. In your case it seems this could be applied here too. If you have further questions on how to actually do this, feel free to ask. I could even create a sample for this use-case if neccessary.

Best regards,
Edwin

Am Mittwoch, 27. Dezember 2017 12:30:49 UTC+1 schrieb Mario Giammarco:

Hello,

I have this use case: a select widget called "filter by" and a widget that can be a text input or date input or numeric input depending on choice made on select widget.

Is it possible to do with Nowicket?

Thanks,

Mario

--
You received this message because you are subscribed to the Google Groups "invesdwin-platform" group.

To unsubscribe from this group and stop receiving emails from it, send an email to invesdwin-platform+unsub...@googlegroups.com.

[sub es]

ah, alright. Will add that. Thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to invesdwin-platf...@googlegroups.com.

To post to this group, send email to invesdwin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/invesdwin-platform/9b97dbdd-85c1-42ad-b47a-8dc17cd1e3bb%40googlegroups.com.

[subes]

Done: http://invesdwin.de/nowicket/validation

To unsubscribe from this group and stop receiving emails from it, send an email to invesdwin-platform+unsubscribe@googlegroups.com.

To post to this group, send email to invesdwin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/invesdwin-platform/771508ba-53eb-45cc-bf92-101abcc7c4be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "invesdwin-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to invesdwin-platform+unsub...@googlegroups.com.

To post to this group, send email to invesdwin-platform@googlegroups.com.

[Mario Giammarco]

Thanks, you are soo fast!

[Mario Giammarco]

I have updated snapshots. Just to be sure I have also deleted .m2 cache but widgets go hidden but the they do not reappear.

Can you please tell me what I am doing wrong?

[Edwin Stang]

Hi Mario,

can you please make sure that on the given request that should enable the field again, you hideXyz method is called properly and returns the correct result?
It should be called automatically from inside de.invesdwin.nowicket.generated.guiservice.internal.SessionGuiService.updateAllComponents(Component):

-----------------------
    private void updateAllComponents(final Component component) {
        final AjaxRequestTarget target = RequestCycle.get().find(AjaxRequestTarget.class);
        final Form<?> form = Components.findForm(component);
        if (target != null && form != null) {
            final MarkupContainer root = (MarkupContainer) Components.findRoot(form);
            try {
                root.visitChildren(new IVisitor<Component, Void>() {
                    @Override
                    public void component(final Component object, final IVisit<Void> visit) {
                        if (object instanceof Form || object instanceof TabbedPanel
                                || object instanceof ModalContainer) {
                            target.add(object);
                        }
                        if (!object.isVisible()) {
                            final List<ModelComponentBehavior> modelComponentBehaviors = object
                                    .getBehaviors(ModelComponentBehavior.class);
                            for (final ModelComponentBehavior behavior : modelComponentBehaviors) {
                                //update visibility manually since onConfigure() will be skipped
                                behavior.onConfigure(object);
                            }
                        }
                    }
                });
            } catch (final Throwable t) {
                if (t.getMessage().contains("longer be added")) {
                    LOG.catching(new RuntimeException("Ignoring exception cause for frozen components", t));
                } else {
                    throw t;
                }
            }
        }
    }
-----------------------------------

The bold code is the fix I had to implement to make the components visible again which I was talking about a few posts earlier. This code gets executed as part of GuiSerivice.get().processRequestFinally(component) which is automatically executed by a model button callback for you. You could either put some system.out statements into your hideXyz() method or debug it to verify it is being called properly.

If you find something that would help in analyzing this further, please tell me your findings. If this is indeed a bug, I would need to reproduce it with either a small sample or additional information. Since at least in the example I provided it works for me.

Best regards,
Edwin

[Mario Giammarco]

Hello,

In your sample the html code (for inheritance and hidden fifelds) is generated automatically or, in this case, you had to generate it by hand?

[Edwin Stang]

Hi Mario,

in the example project, the html code gets generated (and merged after changes) by running the class: de.invesdwin.nowicket.examples.guide.ExampleMarkupGenerator

After that I did only cosmetic changes manually like changing the order of the elements, removing some tags, adding the wicket:enclosure attributes and moving buttons together.

I prefer to manually run the generator to not get something generated while I am not finished coding it. Though if you prefer to run the generator with each build, you can look at the markup generator here: https://github.com/subes/invesdwin-context-client/tree/master/invesdwin-context-client-parent/invesdwin-context-client-wicket-maven-plugin

The description for it is here: https://github.com/subes/invesdwin-context-client#wicket-modules

Best regards,
Edwin

[Mario Giammarco]

I have found the problem. Pulling the code of your examples automatically fixed my problems. Apparently eclipse ignores pom.xml and links my code with the one in its workspace :-/

[sub es]

Ah yes, though you can disable workspace resolution of maven artifacts if you prefer otherwise. Glad the issue is fixed with this. :)

Von: mgiam...@gmail.com Gesendet: 15. Januar 2018 9:59 nachm. An: invesdwin...@googlegroups.com Betreff: Re: Dynamic components

--

You received this message because you are subscribed to the Google Groups "invesdwin-platform" group.

To unsubscribe from this group and stop receiving emails from it, send an email to invesdwin-platf...@googlegroups.com.

To post to this group, send email to invesdwin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/invesdwin-platform/a039aebd-54b9-43b6-b2ac-ec66fd9a37ac%40googlegroups.com.

[Mario Giammarco]

Ok I do the same.

I ask you because I am doing my project following your precious example but my code still not works.

Your List of  IDynamicEditorField is shown perfectly on browser.

Mine works only if I put the class and not the interface in the parent page.

I am looking each class I have written to spot a difference but meanwhile I would like to understand better code generation.

For main model you write a mainPage. 

Then I see for embedded models you create a modelPanel. Is it mandatory to do so?

What triggers right code generation in case of interfaces or abstract classes?

Thanks again,

Mario

--
You received this message because you are subscribed to a topic in the Google Groups "invesdwin-platform" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/invesdwin-platform/ZxofMHbOJTI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to invesdwin-platform+unsub...@googlegroups.com.
To post to this group, send email to invesdwin-platform@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/invesdwin-platform/945343b2-77ab-4c56-b3ec-5a56dd5ba71a%40googlegroups.com.

[subes]

Hi Mario,

to get code generated:
1. create your model (name Xyz), annotate it with @GeneratedMarkup (so that the AnnotatedMarkupGenerator finds the model if you use that)
2. create a page/panel (name XyzPage/XyzPanel and extend appropriately from wicket Panel or Page) for your model (this tells the generator to use wicket:panel or wicket:child as the body tag), the constructors with the new GeneratedBinding(this) are also needed appropriately.
3. run the markup generator (you have to create a launcher for your project for that, e.g. a testcase, a Main class or something

more details in the workflow example here: http://invesdwin.de/nowicket/wicketintegration

For the problem "Mine works only if I put the class and not the interface in the parent page.".
a. I modified the generated html tag for the list from <table> to a <ul> (see
10.4) Tables & Panels here http://invesdwin.de/nowicket/tagtransformations). This causes the binding generator to generate a RepeatingView component (specifically https://github.com/subes/invesdwin-nowicket/blob/master/invesdwin-nowicket-parent/invesdwin-nowicket/src/main/java/de/invesdwin/nowicket/generated/binding/processor/visitor/builder/component/ModelRefreshingView.java), which itself looks up the Panel class for each value of the list. The pattern is <<value.getClass().getName()+"Panel">> for the lookup.
b) The structure in wicket is that a page is displayed and everything inside that is a panel or component. A panel can just aggregate multiple components or panels. This is the same as in Swing with Page=JFrame and Panel=JPanel and Component=JComponent. This is why the sub-models for the editors are generated as separate panels to be leveraged by the <ul> tag.

Best regards,
Edwin

[Mario Giammarco]

Thanks again,

so if I understand correctly if I modify:

public List<IDynamicEditorField> getEditorFields() {
        return editorFields;
    }

to:

public IDynamicEditorField getEditorField() {
        return editorFields.get(0);
    }

I get no html markup generated, right?

To unsubscribe from this group and all its topics, send an email to invesdwin-platform+unsubscribe@googlegroups.com.

To post to this group, send email to invesdwin-platform@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/invesdwin-platform/945343b2-77ab-4c56-b3ec-5a56dd5ba71a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "invesdwin-platform" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/invesdwin-platform/ZxofMHbOJTI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to invesdwin-platform+unsub...@googlegroups.com.
To post to this group, send email to invesdwin-platform@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/invesdwin-platform/b9716ddf-2066-4251-91b7-b40e065e0846%40googlegroups.com.

[subes]

Well, since IDynamicEditorField is not a list/collection but instead directly a type, it is not treated as a reapeatable value but instead treated as a nested model. This will cause it to be treated as a container element inside invesdwin-norva, which currently does not support abstract types (which an interface is too).

Inside https://github.com/subes/invesdwin-norva/blob/master/invesdwin-norva/src/main/java/de/invesdwin/norva/beanpath/spi/ABeanPathProcessor.java, at the following code prevents that (starting at line 109:

--------------- private boolean scanContainer(final IBeanPathElement parentElement, final C container) {

if (container.getType().isAbstract()) {

return false;

     }
---------------

This means you can only use instantiable types as containers inside models. This is because currently the model processor extracts lots of metainformation from actual types and it was not yet needed/implemented to handle abstract types. If you have a valid use case for it, we might consider adding support for that use case. Though in the above example the usage of the interface as a container is wrong and should be used in a collection type for the use case of having different panels instantiated for each value inside a repeatable list.

Though if you mark the getter as @BeanPathEndpoint the framework will interpret the return type as a value instead of a container and thus generate a text property for it that displays its toString(). Also allowing you to override the binding to a different component via a binding interceptor. Here is the adjusted code:
---------------
@BeanPathEndPoint

public IDynamicEditorField getEditorField() {
    return editorFields.get(0);
}

---------------


Thus only container elements cannot be abstract types right now since the framework does not know what to do with it. If you explain a use case for it, we will look into it, otherwise I would look into mentioning this restriction in the documentation somewhere.

Best regards,
Edwin

To unsubscribe from this group and all its topics, send an email to invesdwin-platform+unsub...@googlegroups.com.
To post to this group, send email to invesdwin-platform@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/invesdwin-platform/945343b2-77ab-4c56-b3ec-5a56dd5ba71a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mario Giammarco]

Difficult question.

Actually I have an use case for this.

But before talking about use cases I suppose is acceptable to say that someone that discovers nowicket probably has seen hibernate/jpa that supports inheritance and/or openxava that supports inheritance and/or something else and so on

I personally lost some time because in my brain it was logical to return an abstract type.

But then I see that there is a very easy workaround: you return a List<AbstractType> of size 1.

Probably it is enough to explain in documentation that you can do inheritance with one sized lists.

Or you can modify your framework to create automatically a one sized list when it sees an abstract type.

For me it is the same :-)

Thanks again for interest,

Mario

To post to this group, send email to invesdwin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/invesdwin-platform/945343b2-77ab-4c56-b3ec-5a56dd5ba71a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "invesdwin-platform" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/invesdwin-platform/ZxofMHbOJTI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to invesdwin-platform+unsub...@googlegroups.com.

To post to this group, send email to invesdwin...@googlegroups.com.

[Edwin Stang]

Hi Mario,

I have created a feature ticket for this enhancement to collect further ideas here: https://github.com/subes/invesdwin-nowicket/issues/3

Best regards,
Edwin