Changed in-code html generation to template approach for configuration resource #563

Merged
merged 2 commits into from Oct 22, 2013

Conversation

Projects
None yet
2 participants
@CGijbels
Collaborator

CGijbels commented Oct 12, 2013

It is way to hard to update the content of the Glimpse.axd file (Anthony, it's amazing how long you were able to do that ;-)). But as the Glimpse.axd becomes more and more functional another approach is needed, at least one that allows us to take advantage of VS to have intellisense for HTML, CSS, Javascript etc..

So I looked for a lightweight template engine which is not Razor, because System.Web.Razor needs .NET4 runtime which is not an option for our NET3.5 targets. So instead of coming up with an alternative for 3.5 only, I decided to use one template engine that supports all versions and that one is StringTemplate

The migration from in-code to html template took some time, especially with regards to the <pre> tags, but this PR contains the complete migration to a templated approach for the configuration resource, so it's as fully functional as the in-code approach.

Check it out and let me know what you think...

PS: I already created this PR, because I wanted to see how the ILMerge would work out for that new assembly reference ;-)

Replaced in-code html gen with template approach
New NuGet dependency has been added, so must be ILMerged as well into
Core

@ghost ghost assigned CGijbels Oct 12, 2013

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Oct 16, 2013

Member

This is looking really great and definitely a huge improvement. We have been talking about introducing templates on the client, so it only makes sense that we do the same on the server. Just wondering, do we think its worth trying to use the same templating "language" on the client and server?

Member

avanderhoorn commented Oct 16, 2013

This is looking really great and definitely a huge improvement. We have been talking about introducing templates on the client, so it only makes sense that we do the same on the server. Just wondering, do we think its worth trying to use the same templating "language" on the client and server?

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Oct 16, 2013

Collaborator

when you say

We have been talking about introducing templates on the client

you mean client side templating like Knockout for instance? But the Glimpse.Client already contains separate js and css files, which are manageable?

This light templating engine is really something that runs server side and has no client side version of it. So it depends on what you actually mean with the above quote?

Collaborator

CGijbels commented Oct 16, 2013

when you say

We have been talking about introducing templates on the client

you mean client side templating like Knockout for instance? But the Glimpse.Client already contains separate js and css files, which are manageable?

This light templating engine is really something that runs server side and has no client side version of it. So it depends on what you actually mean with the above quote?

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Oct 16, 2013

Member

Well at the moment, if you want to control the layout, you can supply data structures in given formats which will cause the rendering engine to produce different results. But you can only get so far in the end. If you want to go further, you could create a client side plugin which lets you control the HTML layout, but that seems fairly extreme for those just wanting to create their own layouts and not have any custom client interactions (like timeline or ajax). Does that make sense?

Member

avanderhoorn commented Oct 16, 2013

Well at the moment, if you want to control the layout, you can supply data structures in given formats which will cause the rendering engine to produce different results. But you can only get so far in the end. If you want to go further, you could create a client side plugin which lets you control the HTML layout, but that seems fairly extreme for those just wanting to create their own layouts and not have any custom client interactions (like timeline or ajax). Does that make sense?

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Oct 16, 2013

Collaborator

So if I get this right:

  • You can just send data back from your GetData() method in your tab (and have it optionally processed by a converter), after which the Glimpse client will try its best to create key/valye pairs with lists if applicable
  • As Tab creator, you can also provide a Layout to have more finegrained control about the actual rendering
  • And here you are talking about a third option where you would like to make it easier for Tab creators to just receive their own json object and have them apply it to their own custom template?

If it's the latter, then I wonder whether or not Glimpse must provide the templating functionality, it seems more like something the Tab creators should decide on for their own or do you want to provide a very basic one? Although somewhere I get the feeling that even if Glimpse provides a basic one, it will most likely not be enough for some cases and before you know we have written another Knockout templating engine.

On the other hand, Tab creators can do this already, if we just look at what @grahammendick is displaying in its tab (https://github.com/grahammendick/NavigationGlimpse) and all of that with the current extensibility points.

On the other hand, having something basic would be nice, but the problem is that we don't control the incoming json payload for that tab, so it's difficult to have any idea about what the templating engine is supposed to be able to do?

please correct the flaws in my reasoning, the rendering part is still a little bit fuzzy for me 😉

Collaborator

CGijbels commented Oct 16, 2013

So if I get this right:

  • You can just send data back from your GetData() method in your tab (and have it optionally processed by a converter), after which the Glimpse client will try its best to create key/valye pairs with lists if applicable
  • As Tab creator, you can also provide a Layout to have more finegrained control about the actual rendering
  • And here you are talking about a third option where you would like to make it easier for Tab creators to just receive their own json object and have them apply it to their own custom template?

If it's the latter, then I wonder whether or not Glimpse must provide the templating functionality, it seems more like something the Tab creators should decide on for their own or do you want to provide a very basic one? Although somewhere I get the feeling that even if Glimpse provides a basic one, it will most likely not be enough for some cases and before you know we have written another Knockout templating engine.

On the other hand, Tab creators can do this already, if we just look at what @grahammendick is displaying in its tab (https://github.com/grahammendick/NavigationGlimpse) and all of that with the current extensibility points.

On the other hand, having something basic would be nice, but the problem is that we don't control the incoming json payload for that tab, so it's difficult to have any idea about what the templating engine is supposed to be able to do?

please correct the flaws in my reasoning, the rendering part is still a little bit fuzzy for me 😉

CGijbels added a commit that referenced this pull request Oct 22, 2013

Merge pull request #563 from Glimpse/cgijbels-reworking-configuration…
…-resource-with-template-approach

Changed in-code html generation to template approach for configuration resource

@CGijbels CGijbels merged commit 5743589 into master Oct 22, 2013

@CGijbels CGijbels deleted the cgijbels-reworking-configuration-resource-with-template-approach branch Dec 3, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment