Closed sabracrolleton closed 10 years ago
Awesome! I will look at this in more detail this weekend. Thanks!
Hi there! I think I'm good with all of these additions.
Curious though, what are the use cases for the "role" attribute and the ability to add an attribute to a tag definition?
I probably should not have left the role attribute in the commit. The skeleton pulled in bootstrap and that attribute is needed for bootstrap to work when I was testing, so I added role to the list of attributes. However, since it is bootstrap specific, it probably should not be in the base.
I put in the ability to add an attribute to because so much of the javascript libraries seem to require the use of additional attribute and I did not know whether people would want to edit the taglibrary or just put an attribute in. But hh-web is designed for recompiling the taglibraries, so having a specific function to add an attribute is probably not in keeping with the spirit of hh-web.
Sabra.
On Sat, Sep 20, 2014 at 6:15 AM, Phil Hargett notifications@github.com wrote:
Hi there! I think I'm good with all of these additions.
Curious though, what are the use cases for the "role" attribute and the ability to add an attribute to a tag definition?
— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/pull/10#issuecomment-56267515.
Re role: yeah, if we could take that out of the base, that would be better. That then leaves the question of how to make it easy to add in for bootstrap.
I had to re-acquaint myself with this code, but a few thoughts come to mind:
Thanks. Will redo
Sabra
On Mon, Sep 22, 2014 at 6:35 AM, Phil Hargett notifications@github.com wrote:
Re role: yeah, if we could take that out of the base, that would be better. That then leaves the question of how to make it easy to add in for bootstrap.
I had to re-acquaint myself with this code, but a few thoughts come to mind:
- One can always define a new tag based on another tag--this can be useful for "extending" an existing tag (e.g., with new attributes, etc.), while still delegating to the base tag for rendering. Form element tags do this, for example.
- While this wasn't true of the original design of hh-web, I think attributes are pretty flexible now...so one doesn't have to pre-declare attributes on a tag before actually setting a value when using a tag; hence, there may be no need to pre-declare a "role" attribute--just set the value when appropriate, and left everything work from there.
— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/pull/10#issuecomment-56373127.
Do you want me to delete the add-attribute function?
Yeah, I think for now it's not the right way to go, and isn't strictly necessary.
Ideally, if a tag definition changes (which is what this does), then it would be important to invalid any cached objects dependent upon that tag definition: so templates, generated html, etc., all should rebuilt when a request next accesses them.
Without a richer means of indicating all the things to be rebuilt, plus knowing that it's not necessary, then I think leaving it out is a good idea.
Sound okay?
:)
On Sep 27, 2014, at 12:24 PM, sabracrolleton notifications@github.com wrote:
Do you want me to delete the add-attribute function?
— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/pull/10#issuecomment-57057716.
Agreed.
One additional item that I ran into last night. render-tag-attributes uses single quotes. Is it critical that they be single quotes rather than double quotes? Playing with angularjs last night, I ran into a situation where angularjs needs something to look like xyattribute="'something'". Note the use of both double quotes (on the outside) and single quotes (on the inside). Changing render-tag-attributes to generate double-quotes fixed this, but I have not been able to determine if that causes collateral damage somewhere else. Your guidance would be appreciated.
Sabra
On Sat, Sep 27, 2014 at 9:27 AM, Phil Hargett notifications@github.com wrote:
Yeah, I think for now it's not the right way to go, and isn't strictly necessary.
Ideally, if a tag definition changes (which is what this does), then it would be important to invalid any cached objects dependent upon that tag definition: so templates, generated html, etc., all should rebuilt when a request next accesses them.
Without a richer means of indicating all the things to be rebuilt, plus knowing that it's not necessary, then I think leaving it out is a good idea.
Sound okay?
:)
On Sep 27, 2014, at 12:24 PM, sabracrolleton notifications@github.com wrote:
Do you want me to delete the add-attribute function?
— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/pull/10#issuecomment-57057716.
— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/pull/10#issuecomment-57057807.
I'd say go ahead and change the rendering to use double quotes. I think that is a relic of a quirk of mine several years ago, and certainly doesn't align with conventional use.
Anything that breaks because of the change to double quotes would be worth fixing. Good catch!
:)
On Sep 27, 2014, at 12:58 PM, sabracrolleton notifications@github.com wrote:
Agreed.
One additional item that I ran into last night. render-tag-attributes uses single quotes. Is it critical that they be single quotes rather than double quotes? Playing with angularjs last night, I ran into a situation where angularjs needs something to look like xyattribute="'something'". Note the use of both double quotes (on the outside) and single quotes (on the inside). Changing render-tag-attributes to generate double-quotes fixed this, but I have not been able to determine if that causes collateral damage somewhere else. Your guidance would be appreciated.
Sabra
On Sat, Sep 27, 2014 at 9:27 AM, Phil Hargett notifications@github.com wrote:
Yeah, I think for now it's not the right way to go, and isn't strictly necessary.
Ideally, if a tag definition changes (which is what this does), then it would be important to invalid any cached objects dependent upon that tag definition: so templates, generated html, etc., all should rebuilt when a request next accesses them.
Without a richer means of indicating all the things to be rebuilt, plus knowing that it's not necessary, then I think leaving it out is a good idea.
Sound okay?
:)
On Sep 27, 2014, at 12:24 PM, sabracrolleton notifications@github.com wrote:
Do you want me to delete the add-attribute function?
— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/pull/10#issuecomment-57057716.
— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/pull/10#issuecomment-57057807.
— Reply to this email directly or view it on GitHub https://github.com/hargettp/hh-web/pull/10#issuecomment-57058735.
Added the ability to generate hunchentoot easy-ssl-acceptors
Cool stuff! I'll take a look at it over the next few days. The SSL support especially seems like a great thing to add!
Added an html5 tag library, (skeleton still defaults to the standard html library) Updated jquery and bootstrap library versions in the skeleton, Added js, css and images directories in the skeleton. You might want to put them all under a static directory. Added "role" as a default attribute to tags (You may or may not want to keep that). Added an add-attribute function which just pushes a new attribute into a specific tag. (You may or may not find this useful) Added the ability to set language, doctype and charset to html and page. Doctype now defaults to html rather than html4.01