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 <cziege...@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 <cziege...@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 <j...@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 > >>> cziege...@apache.org > >>> > >> > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
