I'm trying to change class for Pager from pager to pagination as it's conflicting with bootstrap classes.
It's defined in CoreShapes.cs with
Shape.Classes.Add("pager");
I managed to add classes I need by overriding Pager.cshtml
#{
// number of page number links to show, 0 means no link, 1 means only the current page, or more accepted.
Model.Quantity = 5;
Model.Metadata.Alternates.Clear();
Model.Classes.Add("pagination pagination-sm");
Model.Metadata.Type = "Pager_Links";
}
#Display(Model)
This results in list that has class="pager pagination pagination-sm".
Is it possible for me to remove the pager class without modifying CoreShapes.cs or using javascript? Already tried without success:
Model.Classes.Clear();
Related
I need a load more button to control the repeater shown content.
Here is my steps in the back end after load more button was clicked:
Repeater bind data (Full data/All rows).
Keep the maximum items count (static) from the repeater.
Set total row to show (static) + 1 and initialize the value to select top N row as the limit.
Repeater bind data again (The amount to show only).
Check if repeater items count is less than maximum items count, if not then hide the load more button.
Suppose these steps can give me the expected output?
//Declaration
public static int max = 0;
public static int totalShow = 0;
//SetupControl()
if(!IsPostBack){
rptItems.ClassName = "Blog";
rptItems.Path = "/Shared/%"
rptItems.DataBind();
max = rptItems.Items.Count();
}
//This part is put under a new function
totalShow += 1;
rptItems.SelectTopN = totalShow;
rptItems.DataBind();
lbnLoadMore.Visible = rptItems.Items.Count() < max;
Besides, I'm confusing about the functions as shown below:
Both are from the class CMSRepeater, what's the different? Which one should I use in order to set the limits?
Using static members is definitely not a good approach. Their values would be shared by all users of the application. There are better ways of storing user-specific data:
session (server-side)
JS (client-side) and passing them to the server via query string or hidden field
Regarding TopN and SelectTopN, they do the same thing. It's probably because of backward compatibility.
From the algorithmical point of view, there's no need to bind data multiple times nor to make more than one round-trip to the database. You just need to initialize the datasource/repeater with correct values.
I'd recommend you reading the following articles to get some inspiration:
Turn a Kentico repeater web part into an infinite scroll / lazy loader by Laura Frese
Dynamic jQuery AJAX viewer by Jan Hermann
i have a problem with the Dialog control from the Extention library:
I have created a java custom control wich searches some views, collects some data and displays it. This works nice if i place it on a XPage.
But i want to display the data in a Dialog so i used the Dialog control from the extention library. Using the Dialog control without any configuration also works fine but it takes some time for my control to search the views and display the data every time i open the dialog.So to reduce the waiting time for the user i wanted to use the option "keepComponents="true" from the Dialog control.
Now if i open the Dialog for the first time everything is perfekt but if i open it a secound time it displays the content from the first opening in addition to an error from my controlRenderer wich tells me that it could not get the viewName from the control. This error stacks up for every time i open and close the dialog.
I found a Post on OpenNtf from somebody who had the same issue with multiple content in his dialog when using this option but he didnt get any answers to his question.
Is this a bug of the component? Should i forget this option and cache my data in a bean? Why can't the renderer get the Viewname from the component?
The answer that follows assumes that the phrase "java custom control" in your question refers to a JSF component you developed; in XPages, the term "custom control" usually refers to an instance of a Custom Control design element, which is IBM's implementation of the JSF notion of "composite components".
You've stated that the component initially behaves as intended but fails on subsequent requests. This typically indicates that the restoreState and saveState methods of the component have not been properly implemented.
When the default serialization options are enabled for an application, all component state is written to disk at the end of each request, and read back into memory at the beginning of the next. These two operations are handled, respectively, by the saveState and restoreState methods of each component.
For example, suppose you defined a component for adding HTML canvas tags to an XPage, and decided to support the gesture and touch events associated with that element. So your component class would contain fields to store any code bound to those events:
private String ongesturechange;
private String ongestureend;
private String ongesturestart;
private String ontouchcancel;
private String ontouchend;
private String ontouchmove;
private String ontouchstart;
Each of those fields would typically then have an associated "getter" and "setter" method:
public String getOngesturechange() {
return getStringProperty("ongesturechange", this.ongesturechange);
}
public void setOngesturechange(String ongesturechange) {
this.ongesturechange = ongesturechange;
}
When an instance of that component is initialized, the "setter" method associated with each attribute that is defined for that component instance will be passed the value defined for that attribute. For the remainder of the initial page request, then, the private field for each defined attribute will store the value that was set. At the end of the request, the saveState method writes the values of these fields to disk. A typical saveState method looks similar to the following:
#Override
public Object saveState(FacesContext context) {
Object[] properties = new Object[8];
int idx = 0;
properties[idx++] = super.saveState(context);
properties[idx++] = this.ongesturechange;
properties[idx++] = this.ongestureend;
properties[idx++] = this.ongesturestart;
properties[idx++] = this.ontouchcancel;
properties[idx++] = this.ontouchend;
properties[idx++] = this.ontouchmove;
properties[idx++] = this.ontouchstart;
return properties;
}
The call to super.saveState() executes the same method, but using the version of the method defined in the parent class. So the on-disk representation of each component is essentially a nested array: each layer in the hierarchy stores all the properties it inherits from its parent class in the first element of the array, then stores all the properties that it defines in additional array elements.
When the component tree is restored on subsequent requests, each component uses its restoreState method to reconstitute the values of all its fields. A typical restoreState method looks similar to the following:
#Override
public void restoreState(FacesContext context, Object state) {
Object[] properties = (Object[]) state;
int idx = 0;
super.restoreState(context, properties[idx++]);
this.ongesturechange = ((String) properties[idx++]);
this.ongestureend = ((String) properties[idx++]);
this.ongesturestart = ((String) properties[idx++]);
this.ontouchcancel = ((String) properties[idx++]);
this.ontouchend = ((String) properties[idx++]);
this.ontouchmove = ((String) properties[idx++]);
this.ontouchstart = ((String) properties[idx++]);
}
This hierarchically reads the on-disk data back in: each class passes a set of properties to the parent class, then assigns the remaining array elements to the fields they were associated with when the component state was saved.
This process provides an easy way to maintain component state across requests -- each layer of inheritance need only concern itself with the new properties that layer defines -- but these state maintenance methods are easy to forget to implement. If either method is omitted from the component implementation, then the page "forgets" the property values on subsequent requests, because either they were never written to disk, or were not loaded back into memory, or both.
Assuming that this is the root cause of your problem, the reason the problem does not occur when the component is inside a dialog with the default (false) value for keepComponents is because the default dialog behavior is to remove its children from the component tree entirely when the dialog is closed. This behavior is for performance reasons: there's theoretically no benefit to be gained from storing a server-side representation of components that only exist inside a dialog that the user is not currently interacting with. When the dialog is opened again, a new instance of each child component is created using the original property values. In this scenario, it wouldn't matter that your component isn't saving its state, because each time it's used, a new instance is created. But if the dialog is told to keep its children in the component tree, now the component must properly maintain its own state... otherwise its property values are discarded at the end of each request and subsequent requests are unaware of the previous values.
In summary, yes, the data you're displaying should be cached in a bean (or data source) if the data is unlikely to change enough between requests to justify obtaining the data again during every single event. But the reason for the specific behavior you're describing is most likely because your component implementation is not properly maintaining its own state.
I'm using Dialog and would like to style all my cells. I have a background image, and in the samples I can see how you can use a StyledStringElement to use that image.
However, in real use some sections use other elements. For example the last element in one section is a RootElement - but it has no BackgroundUri property to set. The same would go for boolean elements.
I found this question - What's the best way to customise all monotouch.dialog TableViewCells to the same style (Background, etc..)? which is a similar question a year and a half back. The UIAppearance styling mentioned does exist for tablecells but does not work with MTDialog. krtrego's answer to this In monotouch.dialog can RootElement be easily styled? question purports to do the job, but no styling occurred when I implemented it.
Is there now any improved way to do this? Implementing my own 'styled' versions of these other control types would be a big effort and looking at the styledstringelement this is beyond my current skill level.
Here's an example of what I'd like to achieve (the shadow below the 'tags' cell, but the element is actually a RootElement with a set of radio options beneath it). Removing the default grey lines etc is easy enough, but putting a subtle shadow on the bottom cell of each section is what I cannot work out.
Many thanks!
PS. With a normal MTDialog screen with cell backgrounds and borders removed, there is a subtle white shadow/line beneath each section as it is. If I could just recolour that I'd be a long way to where I want to be...
Subclassing the element will let you style it via overriding the GetCell method, but that gets pretty tedious. The best solution I have come across is to to make a custom DialogViewController by subclassing it, and overriding the CreateSizingSource method with your own SizingSource and GetCell() methods using the images you want for each scenario of a cell (top, middle, bottom, alone). Its a bit of code and my example wont handle uneven rows, but it is the only solution I have seen that does not modify the MT.D source code.
Here is what you would override in your DialogViewController subclass:
public override Source CreateSizingSource(bool unevenRows)
{
return new CustomSource(unevenRows);
}
Then you would make a custom source class:
public class CustomSource : Source
{
public CustomSource(DialogViewController parent) : base (parent)
{
}
public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
{
var theCell = base.GetCell(tableView, indexPath);
if (RowsInSection(tableView, indexPath.Section) == 1) //use one with top and bottom rounded
{
theCell.BackgroundView = new UIImageView(Theme.CellBackgroundFull);
theCell.SelectedBackgroundView = new UIImageView(Theme.CellBackgroundFullActive);
} else if (indexPath.Row == 0) //top only
{
theCell.BackgroundView = new UIImageView(Theme.CellBackgroundTop);
theCell.SelectedBackgroundView = new UIImageView(Theme.CellBackgroundTopActive);
} else if (indexPath.Row+1 == RowsInSection(tableView, indexPath.Section)) // bottom only
{
theCell.BackgroundView = new UIImageView(Theme.CellBackgroundBottom);
theCell.SelectedBackgroundView = new UIImageView(Theme.CellBackgroundBottomActive);
} else //anything in the middle
{
theCell.BackgroundView = new UIImageView(Theme.CellBackgroundMiddle);
theCell.SelectedBackgroundView = new UIImageView(Theme.CellBackgroundMiddleActive);
}
return theCell;
}
}
Theme is just a static class that returns UIImages, similar to the example Field Service app from Xamarin. So here I have made 8 images total. 4 to represent the top, middle, bottom and alone for an element. Each has different rounded corners to appear correct. And then a "highlighted" version of each for when its touched.
The big drawback here is you have to do this for every different styled controller you would need. If you are ok with modifying the MT.D source code, you can get a different solution that will allow you to control it at the Section level here: http://fastchicken.co.nz/2012/05/20/earnest-debrief-visual-styles-in-ios-apps-uiappearence-custom-sections-in-monotouch-dialog/
Which has the same effect, but you only need to subclass Section for each different style, which makes including multiple styles in one Root easier. A pull request was made for this change, but Miguel favored the first solution instead, seen here: https://github.com/migueldeicaza/MonoTouch.Dialog/pull/180
I need to find all Html controls which have a given css class.
var htmlControl = new HtmlControl(document);
htmlControl.SearchProperties[HtmlControl.PropertyNames.Class] = #class;
var uiTestControlCollection = htmlControl.FindMatchingControls();
Using the class name works when there is just one css class on the control. If I have more than one css classes applied on the element, can I search for the element by specifying just one css class and not all of them?
Thanks
You can perform a partial match, like so:
htmlControl.SearchProperties.Add(HtmlControl.PropertyNames.Class, #class, PropertyExpressionOperator.Contains);
var uiTestControlCollection = htmlControl.FindMatchingControls();
The main draw back of this is that it is just a simple string compare. To illustrate, imagine you have two controls A and B. A has class "Test" and B has classes "testdiv topnav". Now if you perform a search for "test", both controls A and B will be selected.
To match a class exactly, you can provide a close as match as possible using the above method and write a helper function to:
Loop through the collection
Get the class of each control
Split the class string on the spaces
Loop through this array and test each for an exact match
Keep the elements where a class matches exactly
Note: This is clearly non-optimal - I'm all ears if someone has a better solution.
Cheers,
Seb
I have a GXT Grid showing some "User" objects. One of the columns holds checkboxes (CheckboxCell) . I need to disable a checkbox for 1 particular user and leave others enabled.
I tried extending CheckboxCell class - it's useless because it does not know the context (which User is renders): it only knows about true/false state.
tried
GridView view = table.getView();
Element cell = view.getCell(0, 1);
cell.setAttribute("disabled", "disabled");
-no luck. the disabled attribute is set on the outer "td" tag instead of the child "input" element.
tried cell.getChild..() methods - they all throw "method does not exist" exceptions.
UPDATE: I ended up creating my own CheckboxCellWhichCanBeDisabled class extending AbstractEditableCell. I'm afraid there's no other way.