Hi,
On 1/27/22 5:52 PM, Martin Terra wrote:
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?
Disclaimer: The following is just my opinion.
I think, something like this would be a DSL, because it's a language
specifically designed to describe UIs. Internally, there might even be
two DSLs. One for modeling and describing a UI as pojos, XML, JSON or
functions (in this specific example it's the sealed interface Html) and
one for creating instances of these things (what you see as div {
text("Hello") }). And then there might be other DSLs for specific
frameworks.
Creating a DSL for describing UIs generally and trying to abstract away
Wicket specifics, to then write some Wicket specific renderer again is
something I have tried in the past and I just don't see the practical
value, since it just makes the implementation much more complex. But
maybe I misunderstood you.
Hopefully, this answered your question.
**
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
Matthias
