I have the following code (only relevant attributes included):
<ice:inputText styleClass="myClass" />
renders as
<input class="myClass" />
which is perfectly fine, but
<ice:inputText styleClass="myClass" disabled="true" />
renders as
<input class="myClass-dis" disabled="true" />
so the original style class is no longer applied.
Now, of course I could change my CSS to accomodate for that, but I have several different classes for differently styled input fields, which would all need to then have their own -dis version. This is especially annoying since the disabled style is the same for all of them and the normal CSS way is perfectly suited to handle this: simply combine classes to add the desired look to whatever the standard style is.
So, is there a way to stop IceFaces from automatically affixing my style classes (e.g. like prepending form-IDs can be controlled)?
Related
since our AEM guy is out of office at the moment, i need to fix something in our CRX. I have a form with a checkbox in my website, where authors can set a text next to it. Now i am trying to add the functionality to set this checkbox to be required from the authoring dialog.
I was able to find a textfield which has this property in authoring, but in the html in CRX i only see the code required=${required}, where other fields like label are shown like ${properties.label} and have a corresponding node in CRX. I don't understand how the required is implemented and need help here.
I already tried to add required=${required} to my checkbox input markup, but this did not work, since in the authoring dialog there still was no checkbox/switch to make the field required (which was kinda expected).
this is the line in the markup which should be required if the author sets it to required in the authoring dialog:
<input required="${required}" type="checkbox" name="campaignform-termsofservice"/>
this is the whole html of the checkbox i want to be able to make required:
<div data-sly-test="${!empty}" class="form__text">
<label class="maut-checkbox--container">
<input required="${required}" type="checkbox" name="campaignform-termsofservice"/>
<span class="maut-checkbox--checkmark"></span>
<span>${properties.checkboxtext #context='html'}</span>
<div>${properties.tncText}</div>
<div style="color:white;" class="authoring-error" data-sly-test="${wcmmode.edit && !tncDate.tncLinkActivationDate}">${'b2x.maut.campaignform.dialog.tos.activationmessage' # i18n, source='user'}</div>
<input type="hidden" name="maut.field.tnc" value="${tncDate.tncLinkActivationDate}" />
</label>
</div>
Now i only need to figure out how i can show the option to set it to required in the authoring dialog.
Thanks in advance
If you want to know how the required=${required} is implemented then first of all in html of the component look for something like data-sly-use.required. This will have a expression like =com.project.yourProject.className or some js file.
Lets discuss about the java case which is the most common way. What data-sly-use does is that it creates an object of the class that you gave in the expression. In your case your object is required. Then you need to check the java class that the expression evaluates to. Commonly all the backend logic code will be their and if some manipulations or validations are required to be done with the data that the author enters in the dialog will be their. This class will also contain annotations that maps the class variables with the property value of the dialog.
Hope this explains from where this ${required} came from. It will be more clear to you if you look into the java class that is referred to by the data-sly-use expression.
So a standard html attribute is one with the attribute name on the left and the value in quotes on the right. (class="buttons")
To change something on an element in Ionic the syntax is value name only, no quotes.
However I've noticed that sometimes that value is called a directive, other times a property and other times an attribute. What's the difference?
Here are examples of each from the docs :
buttons use a standard element, but are enhanced with an ion-button directive.
<button ion-button>Button</button>
The color property sets the color of the button. Ionic includes a number of default colors which can be easily overridden:
<button ion-button **color="light"** >Light</button>
// what I consider an attribute is being called a property here.
To use the outline style for a button, just add the outline property:
<button ion-button color="light" **outline** >Light Outline</button> //outline is called a property as well.
Add the large attribute to make a button larger, or small to make it smaller:
<button ion-button **large** >Large</button>
//large is being called an attribute here. Why not call it a property or a directive?
Does any of it make a difference or no?
Button is one of Angular components which Ionic is largely consist of. So to get it short:
ion-button is a component which is build upon [ion-button] selector as you can find it here in source
color, outline, large are the inputs of ion-button component as you can also see in source
From the DOM point of view all of these are attributes. Although if you really need to have an exact [attribute] to be compiled by Angular you've got to use [attr.attribute] binding which is not the same for directives/component and its inputs. Inputs are the properties of directives/components at the same time.
Is it possible to build complex taghelper in ASP.NET 5 where the custom tag have child elements/tags of a certain type?
<blockSection columns="2" labelPosition="left">
<inputField for="name" />
<inputField for="email" required="true"/>
</blockSection>
The in the above example, the blockSection will be a TagHelper that only accepts inputField tags.
Without a whole bunch of trickery (parsing a tags body yourself or creating a TagHelper that targets everything) you can't do this 100% today (beta6).
You can partially fix your issue by ensuring <inputField> elements only appear inside of a <blockSection> tag (would not restrict you from putting things like <p> inside of a <blockSection>). Can be accomplished by using context.Items bag to notify an InputFieldTagHelper that it's (or is not) encapsulated by a <blockSection>. See this issue for information on how to communicate between child => parent.
If you're willing to wait for this Razor issue to be completed; you'll be able to enforce what tags can appear inside your TagHelper.
Another similar SO issue for reference.
I just come across a good write up for a new ASP.NET Core feature called Tag helpers.
From there, I understood that one can replace the following code:
#model MyProject.Models.Product
#using (Html.BeginForm())
{
<div>
#Html.LabelFor(m => p.Name, "Name:")
#Html.TextBoxFor(m => p.Name)
</div>
<input type="submit" value="Create" />
}
with:
#model MyProject.Models.Product
#addtaghelper "Microsoft.AspNet.Mvc.TagHelpers"
<form asp-controller="Products" asp-action="Create" method="post">
<div>
<label asp-for="Name">Name:</label>
<input asp-for="Name" />
</div>
<input type="submit" value="Save" />
</form>
There's some new syntax such as asp-controller, asp-for, etc. But what does it do? And what's the advantage of this new approach?
The most important improvement I've seen so far is the control it guarantees over your HTML elements. While convenient, the Html helpers used by MVC create problems when you try to do things they weren't built for.
A simple example can be seen when using the TextBox in MVC5:
#Html.TextBoxFor(m => p.Name)
The resulting HTML markup looks like:
<input class="form-control" id="Name" name="Name" type="text" value="">
Nice and simple. But what if you want to add a placeholder attribute? What if you want to use bootstrap's validation states? What if you have some 3rd party super cool javascript library which needs custom attributes. None of these things were possible in the initial release of MVC5. Though they were eventually added via update in the form of htmlAttributes. Even now adding custom attributes is kludgey at best.
#Html.TextBoxFor(m => p.Name,
new {#class="form-control has-error", placeholder="Enter Name",
superCoolFeature="Do something cool"})
While you could argue this is still less code that straight HTML, it is no longer a significant advantage. Worse, this solution still doesn't cover dashes in attributes which are fairly common. If you need them you are stuck with a workaround such as ActionLink htmlAttributes
I've gone down the route of fixing these deficiencies with custom editors, and tried building my own TextBox controls. It became obvious pretty quickly that replacing the included TextBox templates would require a lot of work. Worse, your templates have to have knowledge of any extensions you are adding to use them.
It seems like the inclusion of Bootstrap and other 3rd party tools into MVC have made it more obvious that the current design has problems with extending HTML which need to be fixed. Hopefully the tag helpers implementation is complete enough that we can avoid them in the future.
Not to mention, your Web Designers will have real HTML tags to edit that they recognize to re-design your pages. Designers shouldn't have to be coders and there's enough for these sharp folks to keep up with, studying the moving targets of HTML5 and CSS3 specs.
A few things come to mind:
As #ChrisWalter points out, these tag helpers give HTML tags an Open/Closed quality. Rather than just letting you write extension methods for common HTML patterns, you can extend an HTML element. This lets you pick-and-mix multiple extensions per component, rather than having to choose between them.
HTML Helpers tend to not work super well for elements that need to have inner HTML provided as an argument. They came up with a clever pattern so you can say:
#using (Html.BeginForm(...)){
{
<input ... />
}
But there's nothing about BeginForm() that would force you to put it in a using statement, and there's nothing to prevent you from using incorrect HTML structure. (<input> technically isn't allowed to be directly inside a <form> tag.)
This gives us a really easy transitional stepping stone into the Web Components world of HTML5. A component that you write today for jQuery or Bootstrap to pick up and enhance may make more sense as an Angular 2 or Polymer component in a few years. Using HTML syntax makes it possible to write your HTML the way you want it to look when it's a web component, and have it automatically translated into the structure it has to take on for now (or for specific browsers, later).
Accepted answer is correct but just a correction.
Html Helpers cover dashes in attributes by use of underscore. for example if you want html like
my-attr=value
then you can use html helpers like
#Html.TextBoxFor(m=>m.id,
new { my_attr = value })
then it will convert accordingly.
I know the original question asks about advantages but for the sake of completeness I have to mention one disadvantage:
With tag-helpers enabled you cannot inject C# code inside tag attributes.
I.e. this code will break:
<!-- this won't work -->
<input class="#GetMyClass()">
<!-- this won't work too -->
<input type="checkbox" #(condition ? "checked" : "") >
To work around this problem you can use custom tag helpers or just disable tag helpers altogether like described in this answer: https://stackoverflow.com/a/65281018/56621
P.S. My humble opinion that can be safely ignored: tag helpers are "magic". And "magic" is always bad in programming. If something looks like an HTML tag, walks like a tag and quacks like a tag - then it should probably be an HTML tag. Without me knowning "oh, it's not *really* a tag".
From building a basic web app from the ground up in .NET 7/Razor pages, I haven't encountered a single instance where a tag helper has an advantage over simply coding the HTML. I don't come from an MVC background so maybe that is where the advantage lies but as seen before...Microsoft has released yet another version of wheel-reinvention that instead of making things easier for some simply adds more confusion to others.
I created this NumberSpinner widget:
<input name="form_action_fy" id="form_action_fy" value="2010"
data-dojo-type="dijit.form.NumberSpinner"
data-dojo-smallDelta="1"
data-dojo-largeDelta="1"
data-dojo-constraints="{min:2010,max:2030,places:0}" />
When I load the page, the widget shows as expected. However, there are a couple of issues:
The value is empty and not 2010.
When I press the decrease button on the empty widget, I get 9000000000000000 and when I increase on the empty widget, I get -9000000000000000. It doesn't stick to the min/max specified.
And, the smallDelta and largeDelta do not work either.
What am I doing wrong here?
Thanks
Eric
In the new widget attribute style the properties that are passed to the constructor function are all put in the data-dojo-props attribute, instead of the ad-hoc attributes of old. In the cases where the docs still point to the older declarative style you might get better luck by looking for the programatic style examples instead.
<input name="form_action_fy" id="form_action_fy"
data-dojo-type="dijit.form.NumberSpinner"
data-dojo-props="
value:2010,
smallDelta:5,
largeDelta:10,
constraints:{min:2010,max:2200,places:0}"
/>
Live example: http://jsfiddle.net/missingno/cQfFt/
Do note that in Dojo 1.6 a couple of widgets are still in transition so some attributes might need to be duplicated in prop and attribute form. Things should be allright in 1.7 though.