to 27. tammik. 2022 klo 23.00 Matthias Metzger (noobyma...@yahoo.de.invalid)
kirjoitti:
> 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.
>
For us the benefit is two-three-fold. First, I'd say
all formcomponents/labels in an ui follow patterns which can be canonized.
Second, reuse.
You can use a label on a panel and you can use the same label in a table to
render (or search) the same data. You can also use it to render a column in
a spreadsheet. Goal is to never implement a label twice.
Or you can use a command item in a menu (or in a button on a panel) to
access the same action. Goal is to never implement an action twice.
Lastly, there are efficiency ganis from centrally tested components which
now furthermore can more easily be automatically tested as they have
standard types and standard expected outcomes.
No more "I forgot to handle that special case again" when you are reusing
the same component type you once already solved.
If you have a new developer, they can start by using the existing
components or creating similar ones. No need to explain wicket potholes
"ah, this is a wicket trick, here you need to do this first before doing
that, and you need to remember this....and in this special case...do that
don't do that" instead they will pick the closest one from library and see
all implementation requirements or hooks it has (optional and required
implementations/extensions).
**
Martin
> 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
>
