In gwt how to get a widget's default style(CSS Selector).For example, gwt button has style name "gwt-button" which is referenced in gwt theme css file.
How to got that programmatically.
Is there any,
DOM.getStyleAttribute();
to accomplish this. GWT experts please help.
In your example of button (or any object that is a child of UIObject) can call getStyleName()
UIObject documentation
String com.google.gwt.user.client.ui.UIObject.getStyleName()
Gets all of the object's style names, as a space-separated list. If you wish to retrieve only the primary style name, call getStylePrimaryName().
Now as to why you need this information is the real question. It is my guess that you want to change the styling of an object (add or remove). This would best be done by either of the following methods.
1) Supplying a custom resources file to the object that has your styling
2) creating a class that extends Composite and create a custom UIBinder class with all of your styles within it.
Related
We have a component that has a child component, within that, there is another child (child-2) component added. When in author ui, child-2 component does have style icon (in component action toolbar); however clicking on that renders a blank list.
If that child-2 component is added as independent component style icon as well as list (when clicked on) is also visible (with all styles variation as defined in policy).
We tried various ways to debug it but can not. Can anyone please help us here
AEM style system works by defining the styles in the policies. These policies should use the exact path where the component can potentially be placed.
Example: If the component's path is
/apps/project/components/content/myheader then the policy will be defined at path similar to below
/conf/project/settings/wcm/policies/project/components/content/myheader/policy_xxx.
But this policy definition will be used in a path in a template where you would use your component. For example if your template name is templateA and the name of the responsivegrid where your component myheader will be placed is headerGrid then myheader's policy will be used here:
/conf/project/settings/wcm/templates/templateA/policies/jcr:content/headerGrid/project/components/content/myheader <cq:policy property>.
The styles defined in policy will then only be visible in the above responsive grid (parsys in old language). To allow this styles in any other path, in your temlate create the path as required and use the policy there.
Following the above example, if you want your stlyes to be available in a componentA in the TemplateA where componentA is placed in bodyGrid then use the policy here:
/conf/project/settings/wcm/templates/templateA/policies/jcr:content/bodyGrid/componentA/project/components/content/myheader <cq:policy property>.
This should resolve your problem as tested in my system. Unfortunately there is no sandbox public to show you an example.
I'm working in react and have an element that uses CSS modules for styling, like so:
<div className={styles.book__title}>Title: {book.title}</div>
Because class names are hashed, the compiled output is something like:
<div class="book__title_adsfj4">Title: The Lord of the Rings</div>
I've added an event listener on a button that, when pressed, adds the 'title' class to this element to offer additional styling for that specific class, like so:
<div class="book__title_adsfj4 title">Title: The Lord of the Rings</div>
Is there a way where I can either:
append a class to an element and within my css file not have that class be hashed or
add a class to an element that exactly matches the final compiled hash name?
Thanks.
I wrote about the best way I've found to do this here - https://github.com/css-modules/css-modules/issues/199
Basically, it's just importing those styles from the original css file. Because those styles are all hashed the same, no matter if they are imported within different files, the styling will carry over.
When you have some kind of event that triggers a permanent visual change on your element, that means your element has state! And you'll want to use state in React to handle that change.
In React, state is a dictionary on a component that, whenever it changes, triggers a re-render of that component. You can read up on state here: https://reactjs.org/docs/state-and-lifecycle.html
What you'll want to do is add a variable into your state, something like 'buttonPressed' (or whatever you want to call that event or status), and have it be set to true or false depending on if you want the class to be there. When the button is pressed, you'll call this.setState to modify the variable in state and trigger a re-render.
Then, in your render function, you'll simply check what that variable is in your state, and include the class or not, like so:
<div className={styles.book__title + " " + this.state.buttonPressed ? styles.title : ""}>Title: {book.title}</div>
It seems that when I use the portal_factory tool for creating an instance of a type it disregards the view I've specified to override base_edit.
Here's what I've got setup:
Alias from edit to base_edit in the types tool.
View class that renders the view.
ZCML that that hooks on the view class to the appropriate interface.
Content class that implements the appropriate interface.
I know my overridden base_edit view works because it renders:
Once the object has been created it renders.
When I disable the portal_factory tool for the type.
When I use another name like custom_edit it also renders the overridden view, despite the type being enabled in the portal_factory tool.
Changing the alias to ##base_edit works too.
this way zope traversing makes an adapter lookup instead of attribute access and your edit view will be used.
afaik the ## forces an adapter lookup, without ## the first object thru acquisition is called and then an adapter
cc #juriejan
You don't need to customized the base_edit.cpt, you simply need to create a new CMF skin template called yourtypenamenormalized_edit.pt, where "yourtypenamenormalized" is your portal_type name lowercase and without spaces.
The original Archetype base_edit.cpt will look for a template called this way before applying all default macros.
After that I suggest you to fill this new template with all the code you'll find inside the default template, that is edit_macro.pt, then start to apply your changes.
Commonly the only macro you'll want to override is the body macro.
I want to change style of textbutton like i want to add background image and i want to change background color using GXT 3.0
someone help me plzzz
Thanks in advance
GXT 3 has a cleaner way to handle these kind of requirements. You have to use Appearance API which is provided in Sencha 3. Here is the key points which is involved in this process.
Appearance Interface, implementation and substitution
Styling with CssResource
Use ClientBundle to fetch css resources
XTemplates to apply styles/properties to mark-ups
In this case what you need to do is to implement an appearance for TextButtonCell (because TextButton uses TextButtonCell as the appearance) and provide required styles using css Style resource (annotating actual .css file path as source) . For example
public interface TextButtonResources extends ClientBundle
{
#Source("TextButton.css")
Style style();
}
Then substitute the built-in TextButtonCell appearance with your one.
<replace-with class="fullyQualifiedNameToYourButtonCellAppearanceClass">
<when-type-is class="com.sencha.gxt.cell.core.client.ButtonCell.ButtonCellAppearance" />
</replace-with>
This blog post has a comprehensive details on this concept
Ext GWT 3.0 Appearance Design
First you set this style in your client side java code:
aButton.addStyleName("my_button_style");
Alternatively, you can use setStyleName() method or even change specific style attributes with setStyleAttribute().
After you've done that in your client side java code, you can define the style in a css file that's loaded for the page.
You can also change the style after component's been rendered. It should properly refresh appearance of your button.
I am having trouble wrapping my head around the spark skin class in relation to it's host component. Basically, from what I've seen with most every skin that comes in the Flex 4 framework they don't directly expose the properties that are dynamically being set in the host component. Instead, they define states that get exposed to the skin class to define when a component should look different. This is all fine and dandy when you have a very simple component with a standard set of states, but when you have twenty different properties (hypothetically) to set in your host component that should change how the skin looks it could get very complicated very fast.
The way that I've seen that they have used to get around this is by overriding the commitproperties and invalidate functions in the skin class, grabbing the values for the properties they want from there, and then setting them to a locally instantiated variable inside the skin class. This is fine, but I feel like that is just a patch workaround to it which makes things a lot more complicated than it needs to be.
HERE'S MY QUESTION:
Is there any way to directly expose a bindable property from the host component class so when you define your skin class it is directly ready to be read from? Let's say you have custom button with a boolean property of 'selected'. In the skin class, you want to add in a get and set function for the property 'selected' so you can perform some action upon your skin whenever it's set. How do you tell the skin class that this is an available property for you to work with from the host component?
This question exists at a very theoretical level. I'm not clear what you're trying to accomplish, nor what sort of properties you're setting on your component class. I suspect, there is an architecture problem if you have 20 properties and each one needs to correlate to a different skin states somehow.
However, I can try to answer your specific questions.
Is there any way to directly expose a bindable property from the
host component class so when you define your skin class it is directly
ready to be read from?
When building Flex MobileSkins, they recommend creating a property named hostComponent which gives the skin class a reference to the component class. MXML skins already have a similar property. If you're using a custom skin, this property is created automatically using the HostComponent metadata. Therefore from the skin class you can access properties on the component class using the hostComponent property.
Let's say you have custom button with a boolean property of
'selected'. In the skin class, you want to add in a get and set
function for the property 'selected' so you can perform some action
upon your skin whenever it's set.
I'm not envisioning the situation where you would want to do this. Generally you would not define any properties on the skin class which you intend to explicitly change on the instance of the skin class.
You could dispatch an event from the component class when the property changes. [This is very common]. Then listen for that event in the skin class using the hostComponent property and change things there.
There is also a way to access the skin class instance from within the component class. So you could change properties directly on the skin class using the skin property.
I wouldn't follow either approach without thinking it through. Ideally the component class and skin class should be encapsulated from each other; and each approach would provide dependencies.
When you affect a skin to a component, you can use metatags to store a reference to the skin part you actually use :
[SkinPart(required="false")]
public var resizeHandle:UIComponent;
Then, when overriding the partAdded and partRemoved methods, you will be able to set or unset whatever you want in these skin parts, from the basic properties to event listeners.
override protected function partAdded( partName:String, instance:Object):void
{
super.partAdded(partName, instance);
if (instance == resizeHandle) {
resizeHandle.addEventListener(MouseEvent.MOUSE_DOWN, resizeHandle_mouseDownHandler);
}
}
override protected function partRemoved(partName:String, instance:Object):void
{
if (instance == resizeHandle) {
resizeHandle.removeEventListener(MouseEvent.MOUSE_DOWN, esizeHandle_mouseDownHandler);
}
super.partRemoved(partName, instance);
}
Furthermore, since you have stored a reference to your skin parts, you can still access it whenever you want in your host component and update it. Am I clear ? :-)