sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Edelson <jus...@justinedelson.com>
Subject Re: Sling 12 themes
Date Wed, 24 Oct 2018 13:16:56 GMT
As I was trying to say, this assumes that modifying the script (or the
model or even the content) is an option. In many cases it isn't. How often,
I don't know, but I'm sure it is more than 5% (although I guess it depends
on how this is measured).



On Wed, Oct 24, 2018 at 1:20 AM Carsten Ziegeler <cziegeler@apache.org>
wrote:

> In addition to that, it seems to me wrong to write a script which
> creates an output (being that html or json or whatever) and then you
> need an additional mechanism to modify this output. Wouldn't it be much
> better to create the correct output in the first place?
>
> So I think there are three places where you potentially do the
> modifications:
> 1. You modify your model which is the input to your script
> 2. You do it in a script
> 3. You reparse the output of your script and then modify it
>
> Maybe there are still use cases for 3 and then the rewriter is a good
> tool for it. But I sincerely hope that 95% of the use cases can already
> be solved with 1 or 2 - and thats were we should focus on.
>
> Carsten
>
> Am 24.10.2018 um 06:55 schrieb Carsten Ziegeler:
> > As usual we're giving ourselves and our users a hard time as we want to
> > support all the possible options in the world instead of focusing on one
> > or two options and make them as good as possible. I don't care what the
> > solution is, but supporting 5 different ways of creating html is imho
> > totally wrong and fragmenting our user base. Whether it is HTL or not is
> > a different question.
> >
> > The current architecture of the rewriter is not optimal as it needs to
> > reparse the output which is expensive. The servlet API has no support
> > for streaming text based outputs so as long as we have that API in
> > between we have a bad solution. Building on top of something where we
> > know that its not a good thing, seems wrong to me as well.
> >
> > Carsten
> >
> > Am 24.10.2018 um 01:45 schrieb Justin Edelson:
> >> Just my 2cents as a fan of the rewriter.
> >>
> >> The problem with saying "just use HTL" (aside from what Jason said) is
> >> that
> >> it enables a separation of concerns. To say "just use HTL" implies that
> >> there is a single developer (or organization) who "owns" all the code
> >> responsible for generating HTML and has the authority to change them to
> >> suit emerging requirements (which today can be done universally via a
> >> rewriter transformer). But this isn't really the case a lot of the
> >> time --
> >> there's multiple "owners" who are each contributing components and
> >> applying
> >> rewriter-style logic across those owners is complicated (if not
> >> impossible)
> >> to manage. This also assumes that HTL (or any other scripting language
> >> generating HTML) is actually being used properly -- in my experience,
> >> there's plenty of "raw" HTML being output from string properties and you
> >> need a way to rewrite that too.
> >>
> >> I really don't think all the rewriter use cases boil down to link
> >> rewriting.
> >>
> https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13
> >> is
> >> a real-world example. But I'll need to dig through my project archive to
> >> come up with good examples.
> >>
> >> Personally, I'd suggest that HTL could be more tightly coupled to the
> >> rewriter and rather than emit a character stream which gets parsed into
> a
> >> SAX stream, the rewriter could be reimagined as a more generic event
> >> stream
> >> processing chain and HTL is directly providing HTML events into this
> >> chain
> >> (and given that HTL knows the output context, it could indicate as
> >> part of
> >> the event that the text content should be parsed in the case of embedded
> >> HTML). The output of JSPs could be parsed as is the current state. JSON
> >> could be handled through different event types.
> >>
> >>
> >>
> >>
> >> On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler <cziegeler@apache.org>
> >> wrote:
> >>
> >>> The rewriter as it is today is pretty heavy and adds a lot of overhead
> >>> to request processing. Especially as the output needs to be created
> >>> first and then parsed again.
> >>>
> >>> There is nothing wrong with enhancing it in general. But for example if
> >>> you use HTL we could provide much better and faster support ootb. I
> >>> think if JSON is rendered we could do something at JSON creation time
> >>> instead of needing to reparse it again as well.
> >>>
> >>> I agree that it gets pretty hard to come up with a solution that
> targets
> >>> all output formats at once, even with the rewriter concept it's not
> that
> >>> easy. But maybe we can come up with different implementations that
> share
> >>> a single configuration. For example for link rewriting that should be
> >>> possible.
> >>>
> >>>
> >>> Carsten
> >>>
> >>> Am 23.10.2018 um 21:43 schrieb Daniel Klco:
> >>>> I don't see how we could support multiple templating languages without
> >>> some
> >>>> sort of rewriter support.
> >>>>
> >>>> Part of the problem IMO is that the Rewriter library muddles the
> >>> rewriting
> >>>> concept with an expectation of specifically dealing with (X)HTML.
> >>>> Instead
> >>>> it would make more sense to me to have a content agnostic library for
> >>>> performing content rewriting and providing a HTML, XML and (possibly)
> >>> JSON
> >>>> implementation.
> >>>>
> >>>> On Tue, Oct 23, 2018 at 1:32 PM Jason E Bailey <jeb@apache.org>
> wrote:
> >>>>
> >>>>>
> >>>>> On Tue, Oct 23, 2018, at 1:24 PM, Konrad Windszus wrote:
> >>>>>> I would  rather prefer to get rid of a server side postprocessing
> >>>>>> like
> >>>>>> the rewriter. For HTL I agree with Carsten, we should probably
look
> >>> into
> >>>>>> a generic link rewriting mechanism which allows for custom rewriting
> >>>>>> with a nice HTL plugin. Much less overhead than a Cocoon pipeline
> >>>>>> which
> >>>>>> needs to deserialize and then serialize again...
> >>>>>> Would be interesting to get forward in that regard with Sling
12.
> >>>>>
> >>>>> There is a real world need for html post processing that is not
> >>> dependent
> >>>>> on HTL. The rewriter is already not a core component and something
> >>>>> that
> >>> is
> >>>>> community supported so I don't think enhancing it should be much
of
> an
> >>>>> issue. For what it's worth though I don't like the overhead of the
> >>> existing
> >>>>> pipeline as it is anyway. HTML doesn't have anything to do with
XML
> >>> anymore.
> >>>>>
> >>>>>> For JSON and client side rendering the link rewriting must be
rather
> >>>>>> encapsulated on the client side as well. I don’t think Sling
should
> >>>>>> provide that functionality as Sling is focusing on the server
side.
> >>>>>
> >>>>> Missing a point here I think. If you are focusing on link rewriting,
> >>> that
> >>>>> is something that can only occur on the server side.  Helps with
> >>>>> multi-tenancy and cross linking.
> >>>>>
> >>>>
> >>>
> >>> --
> >>> Carsten Ziegeler
> >>> Adobe Research Switzerland
> >>> cziegeler@apache.org
> >>>
> >>
> >
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message