So, I know that I can represent an ampersand as & or &.
I have found that at least one method of parsing XML does not allow for the abbreviation-based style - only numeric. Is there a best-practice? I want to instruct my team to use the numeric versions because of my experience, but one instance hardly seems like enough reason to convince them.
Which method should we favor?
XML only has a small set of these symbolic entities, for amp, quot, gt and lt.
The symbolic names we're familiar with for ©, etc. for entities exist because of their appearance in the HTML DTD, here http://www.w3.org/TR/html4/sgml/entities.html (although I think most browsers have this baked in).
Therefore, if you are using (X)HTML, get your doctype right, and then follow the links on w3.org to XHTML to see the entities available.
As far as best practices, most people find the symbolic names easier to understand and will use them when available. I would recommend that.
The only reason not to is that there used to be cases in very old browsers when entities wouldn't work-- but I don't believe this is the case any more.
If you mean other HTML entities, with pure XML, only the entities amp, lt, gt, quot, and apos are pre-defined (apos is not available in HTML, but amp indeed should be).
However, all other HTML entities (such as nbsp) will not be available unless defined in the DOCTYPE, so in such a case, using numeric entities may indeed be preferable.
Related
I want to post an alien artifact to my server.
Do I write type="alienArtifact"
or type="alien-artifact"
or something completely different?
I looked here https://jsonapi.org/format/ but is only deals with simple types, "objects".
JSON:API specification is agnostic if you use kebab-case, snake_case or camelCase for field names but it comes with a recommendation:
Member names SHOULD be camel-cased (i.e., wordWordWord)
This recommendation was change in October 2018. It was kebab-case before. Therefor many articles about JSON:API specification and documentation for libraries are still using kebab-case. These arguments were given as main reasons for this change:
camelCased names can be used directly as identifiers in almost all programming languages, making json:api easier to get started with and to work with over time. Dasherized names are usable as identifiers pretty much only in Lisps.
camelCased names are the most common convention in the JS community, and JS is the biggest user of JSON:API
camelCased names are slightly shorter than dasherized (or snake-case) names, which could help with url character limits in
the case of complex filters or other types of complex queries
(e.g., some GraphQL like “deep querying” feature) that we might
serialize into urls in the future.
You could find more details about this change in the appropriate pull request.
I understand that in the past, it was standard for custom headers names to use the prefix "X-" (I'm aware it no longer is considered standard to do this), but I've been unable to find if there is any relationship between this naming convention and the value ("application/x-www-form-urlencoded"). Did it start out as a custom content-type value that was later adopted or something?
I found this link here, which certainly was interesting, but have been unable to find the answer to my question.
Does anybody know the reason this prefix was chosen, and what it signifies?
it was standard for custom headers names to use the prefix "X-"
Actually … no, not at all. To be precise: It has never been a standard, just a best practice. It allowed implementors to introduce new content types and codings without the need to write an entire RFC for it. Nowadays the IANA Media Type Registry is good for that. RFC 6648 put an end to this practice.
The reason application/x-www-form-urlencoded is prefixed in this way (it is listed as a proper MIME type in said registry, btw)) stems from the fact that it is a "custom" method of structuring the query string in a URL. That part has never seen proper regulation. The people behind HTML just went and did it, which fully justified the prefix.
As far as the history: it has the x- prefix because it originated in a proposal from Mosaic—and since it was just a proposal, they used that x- extension prefix to initially define it. But then other browsers implemented it that way too, and nobody ever got around to taking the time to properly standardize an unprefixed alternative, so it just stuck that way, and here were are now.
It can be traced back to a 1993 thread on the www-talk mailing list titled “Submitting input-form data to server”, and in that thread, a September 1993 message from Marc Andreessen:
This is what we're doing in Mosaic 2.0… See
http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/fill-out-forms/overview.html
...for details on what we're up to
That link is broken now but the document, titled “Mosaic for X version 2.0 Fill-Out Form Support” is archived at archive.org. Here’s the relevant excerpt:
ENCTYPE specifies the encoding for the fill-out form contents. This attribute only applies if METHOD is set to POST -- and even then, there is only one possible value (the default, application/x-www-form-urlencoded) so far.
Anyway, application/x-www-form-urlencoded is now formally defined in the URL spec, with algorithms for parsing and serializing it—though the section it’s all defined in has this note:
The application/x-www-form-urlencoded format is in many ways an aberrant monstrosity, the result of many years of implementation accidents and compromises leading to a set of requirements necessary for interoperability, but in no way representing good design practices. In particular, readers are cautioned to pay close attention to the twisted details involving repeated (and in some cases nested) conversions between character encodings and byte sequences. Unfortunately the format is in widespread use due to the prevalence of HTML forms.
Can someone let me know the basic setup of Compound Templating.Is there some reference document provided by Tridion.
You can find all about Tridion's templating model in this documentation topic (login required):
http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/concept_1C08142900B34C21AC8A86DE54C9EECC
There is a very good training available for it, please see:
http://www.sdl.com/services/education-certification/training-product/web-content-management/index-tab3.html
The Modular Templating & Dreamweaver and MS.NET Templating trainings are the one you are looking for.
Some common points to be remembered, off course very generic but still important.
In schema naming Use lower casing on element names and replace spaces by underscore(_).
Use Genric text with Editors Terms of the description text
To show constraints with particular schema fields one can think of Schema facets
Always create TBB with the purpose of re-usability.
In Dreamweaver templates always use RenderField instead of the ##Component.FieldName## syntax to ensure that the SiteEdit feature always works.
During linking don't forget to use “textonfail” attribute.
Make sure parameter names don’t clash with items.
You can resuse TBBs for different purpose with help of different parameter schemas.
Many more generic points could be keep in mind and always follow as Best Practices to avoid rework. I hope the community can extend the list.
As we know that we can assign the variables to Adobe illustrator file. Is it possible to access these variables by using Drupal 7 variables feature?
Short answer: no.
Longer answer: This is theoretically possible, but.
What you're referring to really amounts to rewriting some of the fundamental underpinnings of the internet. This would require, at minimum, extremely innovative development and entirely recreating several major software components. For example:
1) Users' browsers read and render hypertext. They would need to be rewritten to understand AI equivalents of links, pages, and other internet standards.
2) Javacript, Jquery, and other client-side components would need to be rebuilt from scratch. You would also need to invent a new CSS and DOM that their replacements can understand.
3) Apache .... would be mostly okay with some minor tweaks. One or two new extensions at most.
4) PHP (which stands for "PHP hypertext preprocessor" and not "PHP advanced graphical tool") would need to be entirely redone, along with all of it's extensions, integrations, and fundamental concepts.
5) Drupal and all its modules (which are build on the assumption that the output will be hypertext) would need to be substantially retooled. In particular, you would need a replacement for PHPTemplate that accesses AI objects.
So: There's a lot to do. I would say "let's get started," except that 6) AI is a proprietary product and we don't have licenses to develop and extend it.
I think it depends on what you want to do with the resulting file. Are you thinking of a variable data Illustrator document that would be generated from the values in Drupal? If so, I think that is very possible. The Illustrator file format specification is somewhat available, you would just need to process the file without the help of Illustrator (which may present some challenges).
If you want to generate something that would be viewable in a browser you're better off using SVG with some sort of placeholder that you could replace with regular expressions or maybe some XPath queries to get the nodes you want to manipulate and then adding your values there.
As Dominic said, the end use isn't very clear here so the answers are really dependent on what you need to accomplish.
Just found StyleCop, looks like something worth using for my projects. Then I found out you could use it with ReSharper (a tool I've also never used). So I downloaded ReSharper, as well as StyleCop for ReSharper. I'm just a bit confused about it, though:
With just StyleCop installed (no ReSharper), I get yelled at for referring directly to private variables in code-behind. It wants me to instead do this.variable. Alright, fine.
If I use just ReSharper, it tells me to remove all of the 'this' calls I just added. Which one is better?
If I use ReSharper + StyleCop for ReSharper, it now tells me to add 'this' to all private member references (just like StyleCop did all by itself). However, now it also wants me to add 'this' to all of the controls I'm referencing from the .aspx page (i.e., Label.Text = this.variable -> this.Label.Text = this.variable).
I'm so confused. What is the best standard to follow? Or am I just fine doing it the way I am now (Label.Text = variable)?
The key point is consistency. Your particular formatting with regard to this point comes down to personal preference.
Does the extra wordiness provide additional clarity as to which variable you're referencing or does it obscure the meaning by flooding the page with extra text?
This is a judgment call. They do enforce other rules that make sense; however, a large part of what they do is enforce consistency. As #Martin said, feel free to disable rules that don't make sense for your workflow.
Sorry when working on a team it all comes down to understanding the politics; after all, we work to get paid!
If the person that decided your next
pay raise uses StyleCop, then you
should always include the “this.”
likewise if the boss uses ReSharper
you should do what ReSharper says.
There are a lot more important wars to win this, e.g. 10,000 line classes, over sized method
If you are luckly enough to decide what tools (and coding standards) are used yourself, then I would just choose ReSharper and read the “clean code” book.
I think it's up to you which conventions you want to follow (it's a matter of personal preferences). At least in ReSharper, you can edit the rules to no longer show certain warnings/hints.