Regarding the annotation-heavy soup (nice phrase!) - in theory you could remove them because the programming model is completely open for customisation ... it consists of a set of so-called FacetFactory's that introspect the domain classes (or anywhere else you want to specify the semantics) and build up the domain model. In fact, most folk tend to use the associated .layout.xml file for UI hints rather than the @XxxLayout annotations, because making changes doesn't require a recompile. In theory this could be done for other annotations too, if that's your preference.
Regarding pluggable persistence - we support JDO and JPA and in the past someone spiked neo4j and mongodb, so that's definitely doable. But this isn't really the forum to talk too much about Apache Isis, we have a mailing list or a slack channel if you want to learn more. -- Dan On Thu, 17 Nov 2022 at 16:28, Martin Terra <martin.te...@koodaripalvelut.com> wrote: > Thanks, interesting. First impression it's quite some > annotation-heavy-soup. Was hoping for more wicket-like 100% pojo/lambda > approach and more clear divide&conquer separation of > view<->viewmodel<->persistence in a way that I can implement or plug > something else for persistence. > > Anyways, will have a look if it can be used efficiently. > > ** > Martin > > to 17. marrask. 2022 klo 17.17 Dan Haywood (d...@haywood-associates.co.uk) > kirjoitti: > > > There is a plan to add OData support to isis.apache.org, so that a > > collection of objects could be opened in (and perhaps edited through) > > Excel, say. > > > > Dan > > > > On Thu, 17 Nov 2022 at 13:45, Martin Grigorov <mgrigo...@apache.org> > > wrote: > > > > > Hi, > > > > > > I am not sure how much helpful my answer is to you but > > > https://isis.apache.org/ does something similar. > > > Isis defines a model based on your naked objects. > > > And then different viewers visualize the objectis/collections. Apache > > > Wicket is one of the available viewers. REST is another. AFAIK there is > > no > > > POI viewer but there is a plugin for the Wicket viewer that adds > "export > > to > > > Excel" button next to the tables. > > > > > > On Thu, Nov 17, 2022 at 11:48 AM Martin Terra < > > > martin.te...@koodaripalvelut.com> wrote: > > > > > > > Hi! > > > > > > > > Is there a library/example/experience for doing MVVM with wicket (or > > > > something close enough to serve as a useful reference)? > > > > > > > > A practical goal would be to decouple the Wicket stack from other > > layers > > > > and automate gui code generation based on predefined patterns & > layout > > > > design (benefits would be stabilty, testability, predictability, > > standard > > > > practices, maintainability, upgradeability, code generation/ai code > > > > copilot, etc.). > > > > > > > > Preferably it would work even so far that we could plug/attach either > > > > jakarta poi or wicket to the same model and get as output (for > example) > > > > either a html table or excel sheet. > > > > > > > > How it works is, basically you would have a wicket plugin that > > > > "interprets/implements" the model. Alternatively you could have a > > jakarta > > > > poi plugin as well. > > > > > > > > You could also have a mix of the two, for example: an instruction in > > the > > > > model for an action (link, button, etc. rendered by the wicket > plugin) > > > has > > > > an "embedded instruction" to further render an excel sheet via (a > > > different > > > > plugin) jakarta poi as a result of the wicket action (so that when > the > > > user > > > > clicks the link, the user can download the sheet generated by the > model > > > via > > > > a wicket download stream associated with the defined link/action). > > > > > > > > > > > > ** > > > > Martin > > > > > > > > > >
