Hi! I am curious how this would compare to a declarative ui.
You would define your ui in pojo, almost like swing, and then you have a generic rendering helper/factory layer tailored to your project, which then handles *all* the nitty gritty stuff. Only when you create a new feature, would you worry about its targets etc which you would implement onto the rendering helper/factory layer. There might be parts of such structure that could be reusable across projects. Would this overcome the need for DSL, or would you consider it DSL as well? ** Martin to 27. tammik. 2022 klo 17.59 Matthias Metzger (noobyma...@yahoo.de.invalid) kirjoitti: > Dear Wicket Contributers, > > first and foremost thank you for working on and maintaining Wicket for > such a long time and doing such a stellar job with it! > > I have been using Wicket for about 10 years now. So far it has worked > great in a lot of cases. However, having separate markup files and > having to do target.add(component) manually, are the 2 most annoying > things in working with Wicket for me. If there is any interest, I can go > into more detail. > > So, for some time now, I have been thinking about a DSL for Wicket in > Kotlin, akin to kotlinx.html to stop separating markup and components. > You can find the dumbest and most naive thing I could possibly think of > here: > https://gist.github.com/noobymatze/f27ca43f528f1d2e3fe1454baab5f0a6 > > The idea is, that there is a class DSLWebPage, which can be subclassed > to implement an abstract render() method, which defines HTML and > components at the same time. > > ``` > class ExamplePage: DSLWebPage() { > > fun PageBuilder.render() = html { > head { > } > > body { > h1 { > component(Label("greet", "Hello World!")) > text("Some long text.") > } > } > } > > } > ``` > > The render() method will be called during getMarkupResourceStream. The > component function will automatically create a suitable HTML fragment > with a wicket:id='greet'. The problem with this naive approach is, that > it renders the markup + components every time a request is made, > sometimes even twice during a single request. That's because I disabled > markup caching, because the default caching would only render the markup > once. > > There are a few approaches I can see here. > > 1. Define a cache key per instance (dunno maybe a UUID would do here). > Assumption: There is no dynamic HTML. > 2. Call render() in the constructor of DSLWebPage, which could cause > serious troubles. > 3. Cache the markup myself inside the page. I am not sure, whether this > would have any bad consequences. I believe the markup cache may be able > to optimize the storage, which would not be possible in that case. > 4. Call render in onInitialize. That won't work, because > getMarkupResourceStream is called before onInitialize and I haven't > found another method suitable. Maybe I overlooked something. > 5. Just don't cache, I am not sure, what that would mean for performance. > > I would tend to go with Option 1, but is there anything I am overlooking > here? Do you think, any of this might be problematic for performance or > any other reason? > > I apologize, if this should have been asked in the user mailing list. > > Thanks for reading this far. > > Best regards > > Matthias >
