I am using two attributes for table parameters
:table1: frame="none", grid = "none", stripes=none
:table2: frame="topbot", grid = "rows", options="header"
I want to save them in an different file as I want to use them because I want to reuse themn in many different files. How do I get the other files to know these attributes?
For the specific problem, Asciidoc 'include' directive may be enough.
You do not even need to put that part into a separate file. You can put a
// tag::table_attributes[]
:table1: frame="none", grid = "none", stripes=none
:table2: frame="topbot", grid = "rows", options="header"
// end::table_attributes[]
and then you can
include::the_original.adoc[tag=table_attributes]
in other files. (I did not try it, but it should work.)
When things like that come I usually use the Jamal preprocessor I created
https://github.com/verhas/jamal
that also has snipped include possibilities and many other programming capabilities.
Related
More of a best practice question as I don't want to start down the wrong path.
The following link from the Magento Wiki shows how to add Attribute sets programmatically: here.
It also seems you can use the class Mage_Eav_Model_Entity_Setup and access the methods within to add the attributes etc i.e
$groupSetup = new Mage_Eav_Model_Entity_Setup('core_setup');
$groupSetup->addAttributeSet($entityTypeId, $name);
In my mind, the second option is quicker and simpler but is there a rule on how this data should be added? i.e Is one option likely to change whereas another isn't?
I'm creating a widget where there will be 2 types of params:
-The one that can change depending on where we call the widget, those one will be defined in the widget call:
<?php $this->widget('ext.myWidget', array(
'someParams' => 'someValues',
)); ?>
-The one that are the same for all the call to the widget (a path to a library, a place to save an image, ...)
I would like to know what is the best way to define the second type of parameters.
I'm hesitating between making the user define it in the params array in the config file or defining it in an array in the Widget file.
The main advantage of the first option is that the user won't have to modify the Widget file so in case of update his modifications won't be overwritten, but this is not a specific user params so putting it in the parmas array in config file might seem strange.
So what would be the best solution? If there is another one better thant the 2 above please tell me!
Edit:
To clarify my thought:
My widget will generate some images that can be stored in a configurable directory. But since this directory has to be the same each time the widget is called I don't see the point of putting this configuration into the widget call!
This is why I was thinking about putting some params into the config file, in the params array like:
params => array(
'myWidget' => array(
'imageDir' => 'images',
)
)
But I don't know if it is a good practice that an extension has some configuration values in the params array.
Another solution would be to have a config.php file in my extension directory where the user can set his own values so he won't have to modify his main config file for the plugin. But the main drawback of this alternative is that if the user update the extension, he'll loose his configuration.
This is why I'm looking for the best practice concerning the configuration of a widget
Maybe what your looking for is more of an application component than a widget. You've got a lot more power within a component that you have with a widget. It can all still live in your extensions directory, under a folder with all the relevant files, and still be easily called from anywhere but the configuration can then be defined in configuration files for each environment.
When your setting the component in your configs, just point the class array parameter to the extensions folder, instead of the components folder.
Update:
If you do want to use a widget because there's not a lot more complexity, you can provide some defaults within application configurations for widgets I believe, I've never used it myself, see here: http://www.yiiframework.com/doc/guide/1.1/en/topics.theming#customizing-widgets-globally.
But I've found with more complex widgets that a component serves me better in the long run as I can call methods and retrieve options on it much easier and cleaner, but still have everything related to the extension within one folder.
I know this doesn't exactly match the form of www.example.com/class/function/ID/, but what I want to display to the user would make more sense.
This is what I would like to do:
www.example.com/project/id/item/item_id/
So, an example would be:
www.example.com/project/5/item/198237/
And this would be the behavior:
www.example.com/project/ --> This would show a list of projects (current implementation)
www.example.com/project/5/ --> This would show a list of items on project 5 (current implementation)
www.example.com/project/5/item/ --> This wouldn't really mean anything different than the line above. (Is that bad?)
www.example.com/project/5/item/198237/ --> This would show details for item 198237.
So, each item is directly associated with one and only one project.
The only way I can think how to do this is to bloat the "project" controller and parse the various parameters and control ALL views from that "project" controller. I'd prefer not to do this, because the model and view for an "item" are truly separate from the model and view of a "project."
The only other solution (that I am currently implementing and don't prefer) is to have the following:
www.example.com/project/5/
www.example.com/item/198237/
Is there any way to build a hierarchical URL as I showed at the beginning without bloating the "project" controller?
There are 3 options, sorted by how practical they can be:
Use URI Routing. Define a regular expression that will use a specific controller/method combination for each URL.
Something like that could help you, in routes.php:
$route['project/'] = 'project/viewall';
$route['project/(.+)'] = 'project/view/$1';
$route['project/(.+)/item/'] = 'project/view/$1';
$route['project/(.+)/item/(.+)'] = 'item/view/$2';
That is, considering your controllers are item and project respectively. Also note that $n in the value corresponds to the part matched in the n-th parenthesis.
Use the same controller with (or without) redirection. I guess you already considered this.
Use redirection at a lower level, such as ModRewrite on Apache servers. You could come up with a rule similar to the one in routes.php. If you are already using such a method, it wouldn't be a bad idea to use that, but only if you are already using such a thing, and preferably, in the case of Apache, in the server configuration rather than an .htaccess file.
You can control all of these options using routes.php (found in the config folder). You can alternatively catch any of your URI segments using the URI class, as in $this->uri->segment(2). That is if you have the URL helper loaded. That you can load by default in the autoload.php file (also in the config folder).
I just created a GUI using guide in MATLAB for a small project I'm working on. I have amongst other things two text fields for from and to dates. Now I'd like to get rid of them and use a Java date select tool. Of course this is not possible using guide so I need to add them manually.
I've managed to get them to show up by putting this code into my Opening_Fcn,
uicomponent(handles, 'style','com.jidesoft.combobox.DateChooserPanel','tag','til2');
using UICOMPONENT.
But even though it shows up I can't access the date select's attributes, for example
get(handles.til2)
returns
??? Reference to non-existent field 'til2'.
How can I fix this?
Unless you edit the saved GUI figure, the basic handles structure will not include your new component by default.
One way to access you component is to store the handle via guidata, by adding the following to your opening function:
handles.til2 = uicomponent(handles, 'style','com.jidesoft.combobox.DateChooserPanel','tag','til2');
guidata(hObject,handles)
Functions that need to access the handle need the line
handles = guidata(hObject)
to return the full handles structure that includes the filed til2
I want to build custom filtering header for Vaadin tables.
Can you please give some examples or solution to this problem.
I want to add a combo box or check box that will refine the search in the table like Excel columns.
We faced the problem of adding custom filters for Vaadin Table in our project as well.
As a solution we added a dynamic filter form above the table. It has become flexible and agile enough to apply filters.
We created Vaadin Addon in order to share our solution - Lexaden Grid.
You can find more information by the following link:
http://www.lexaden.com/main/entry/lexaden_grid
At the moment it is quite hard to add a custom component to do filtering with to the header of a table. It would require you to make your own version of Table by inheritance/copy&paste (not sure what is enough), and that is something most people wan't to avoid at the moment if anyway possible. The current implementation of the Table component is one of the most complicated components of Vaadin. It is doable if you insist putting components in header, but prepare for some serious thinking to get things to work.
I'd suggest making the filtering of data in containers with components just next/above your table. Hiding the table header is sometimes acceptable if there's no crucial information shown there. If you want something precisely on the header, it would require some empty headers and CSS positioning components on correct place.
You can always group table and other filtering components to one CustomComponent for easier abstraction.
Book of Vaadin is a very good reference for vaadin implementation. The link consist of an example code like:
// Define the properties
table.addContainerProperty("lastname", String.class, null);
table.addContainerProperty("born", Integer.class, null);
table.addContainerProperty("died", Integer.class, null);
// Set nicer header names
table.setColumnHeader("lastname", "Name");
table.setColumnHeader("born", "Born");
table.setColumnHeader("died", "Died");
Is this what you ask for? If it isn't, can you please specify your question a bit more clearly?
edit: Vaadin Sampler also contains handful code samples.