pe 28. tammik. 2022 klo 11.46 Matthias Metzger (noobyma...@yahoo.de.invalid)
kirjoitti:
> Hi,
>
> On 1/28/22 9:18 AM, Martin Terra wrote:
> > pe 28. tammik. 2022 klo 10.12 Matthias Metzger
> (noobyma...@yahoo.de.invalid)
> > kirjoitti:
> >
> >> Hi,
> >>
> >> On 1/28/22 1:47 AM, Martin Terra wrote:
> >>> 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).
> >>>
> >>
> >> I am not sure, I am following here. To clarify: You are arguing, that
> >> the DSL I've shared should not be done like that, because it would be
> >> better to solve the problem of a declarative, generic UI, that can be
> >> "compiled" (in the sense of factories/adapters) down to Wicket?
> >>
> >
> > Well, there might be some (cross-project) reusable paradigms and patterns
> > and templates, which we could call dsl.
> >
> > I'm not arguing, just bringing up an alternative approach for
> > consideration, maybe they could co-exist as well.
>
> Gotcha! So, to answer your question from the beginning: How does a
> declarative UI compare to the approach I shared (whether we call it a
> DSL or something else). I think a declarative UI would just be a
> generalization of the approach I took here. They might co-exist or the
> this approach could iteratively be generalized. Not sure, how good that
> would work though, since especially the Ajax-Handling in Wicket is
> probably difficult to abstract. Phoenix LiveView might be an inspiration
> here.
>
In my experience the ajax is mostly between the components and you can plug
the data to the components via the models.
Normally you would have patterns, but if you adhere well enough to
patterns, you could use reusable components as well.
Following this line of thinking, why stop there, make the whole page
reusable, as it is quite rare that different pages of the same application
would be so different that reuse wouldn't bring huge benefits.
> However, as far as I can see, when it comes to actually implementing the
> adapters - the nitty gritty, as you rightly called it - (which is
> essentially, what I am doing here), the same questions would come up in
> both approaches:
>
> - Is using the IMarkupResourceStreamProvider and the
> IMarkupCacheKeyProvider the way to go or are there any other ways? For
> example, would it be wise to subclass MarkupContainer or Component to
> implement this?
>
We use IMarkupResourceStreamProvider mostly to implement "unorthodox"
components (which can still be reusable), but if a reusable component is
easy to do in wicket, I would prefer to do it the old way.
Ofcourse one extreme would be to generate the html/css/js via dsl also, but
that might be a bigger project than the whole wicket?
How do you see your proposal w.r.t something like
https://github.com/xmlet/HtmlFlow ?
> - Are there performance/caching/framework problems if you re-render the
> markup and components on every request?
>
We have actually used this to improve performance, and cache the result
also.
> - Is mitigating that, by just rendering the markup once per
> component/page viable or would that lead to a MarkupCache growing
> linearly with the amount of rendered pages and therefore explode the
> memory usage?
>
This might be a "premature optimization" issue, probably just do it and
optimize on demand.
> Or am I missing something? I don't see, how a declarative UI would
> circumvent these questions. Except, if there was a compile step, which
> would compile it down to Wicket code.
>
Now it feels like the declarative ui would be the higher level (think "the
marionette puppeteer") and this dsl would be on the implementation or
framework level, how the components are actually built.
One question is, assume you have a canonical (minimum) set of declarative
(or otherwise) reusable components, what is the benefit from the dsl if
those are quite easy to implement without dsl?
**
Martin
>
>
> Best regards
>
> Matthias
>
