Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify Partials as Views #64

Open
ivargrimstad opened this issue May 6, 2021 · 2 comments
Open

Specify Partials as Views #64

ivargrimstad opened this issue May 6, 2021 · 2 comments

Comments

@ivargrimstad
Copy link
Member

Prosed syntax:
<filename>::<elementId>

Example: Add a row to a table in the view

@ivargrimstad ivargrimstad added this to the 2.1 milestone May 6, 2021
@erdlet
Copy link
Contributor

erdlet commented Sep 16, 2021

Hi all,

after thinking a lot about this idea, I'm asking myself if this is really a feature we should specify it in depth. I had a look into a few template engines we support in Krazo and not all can render partials. So these are my insights:

  • JSP isn't able to render partials without external libs (I think Tiles was able to do this, but thats deprecated since a long time) but we need to support it by default. This would imply for me, that we'd need to implement some custom mechanism for that in the RI which is a lot of work for an old technology like this.
  • Most of the engines I saw don't support partials or partial rendering out of the box and I\m afraid this would also lead to something selfmade in the RI.
  • In case we'd need to implement some partial extraction by ourself, I'm afraid this would need a lot of performance optimization to be helpful because we'd likely render the whole template and extract the relevant parts.
  • In case the template engines are able to render partials, they all work different. Thymeleaf Core has ITemplateEngine#process whereas Handlebars has a completely different mechanism.

As another point, the common way I know of using partials in server side rendered web applications is to use AJAX for progressive enhancement, which bypasses the whole complexity on server side by extracting relevant parts on the client. And even if there is a functionality to render partials on the server, the applications need to use AJAX to fetch them. The only benefit the users would have is a little performance improvement, which I guess can be easily killed by the server side partial mechanism.

Because of this points, I think it makes sense to specify a kind of indicator if an ViewEngine implementation is able to render partials, but don't define anything further. The real work would then be inside the different view engines and we don't add things that might be a pain in the future to the spec and the RI.

@chkal
Copy link
Contributor

chkal commented Sep 19, 2021

Hey @erdlet,

thanks a lot for the summary. I agree that there are different approaches for implementing partial page reloads.

A simple form is already possible today by simply sending a request to the server via JavaScript, fetching the whole page, extracting the relevant part on the client and perform the DOM update manually. I created a small demo app for this a few years ago, which is available here. The JavaScript part is pretty simple, see here.

Of course, it is not very efficient to fetch the whole page just for updating a specific part of the page. To optimize this, we would need support for this approach on the server side. But as @erdlet already described, most of them doesn't support this concept, especially JSP. It MAY be acceptable to let the view engine render the full view and post process the output by using jsoup or some other mechanism. However, this isn't a good idea from a performance perspective, because we need to buffer the response AND the view engine still renders the full page. The only good aspect with this approach is that we sent less data to the client via the network.

IF we want to support partial rendering on the server side, I agree that it should be up to the ViewEngine to actually perform the necessary steps. Not sure yet how the API could look like. Any ideas?

@erdlet erdlet modified the milestones: 2.1, 3.0 Aug 12, 2022
@erdlet erdlet removed this from the 3.0 milestone Oct 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants