hi ludovic,
inheriting folder names that way would break other use-cases and it's also
against the overall concept
(+ it can lead to more complex path-configs easily as well as to potential
clashes in case of multiple interfaces which contain meta-data for the
path-name,...).
i just used that annotation for the discussion (to be sure that we are
talking about the same).
we could extend @ViewConfigRoot to support e.g.:
@ViewConfigRoot(virtual = true)
public interface Pages extends PagesCommon {
//...
}
for sure that would only work for the root-node.
however, all options i've seen so far are more complex than just using
@Folder(name="/") (or they would break other use-cases).
regards,
gerhard
2015-05-20 10:14 GMT+02:00 [email protected] <[email protected]>:
> On 19/05/2015 19:32, Gerhard Petracek wrote:
>
>> hi ludovic,
>>
>> what you are asking for would mean something like:
>>
>> @VirtualNode //instead of @Folder(name="/")
>> public interface Pages extends PagesCommon {
>> //...
>> }
>>
>> so that you have an interface which contains all view-configs, but it gets
>> skipped when it comes to path names.
>>
> Yes.
>
> Or, maybe, rather than adding an annotation, take in account inheritance
> when processing @Folder.
> If class A inherits class B and they both address the same folder, it
> could be ok.
>
>
> Ludovic
> |
> | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
> |
>
>
