I have a lot of bug from my tests runs and I would like to manage them more easilly.
How is it possible to activate tags on bugs definition ?
In that case, I would be able to define tags as "New", "In analysis", "In correction", "In test", "Validated" within any open bug.
Thanks a lot
For now, I used naming convention in bug title, using "[New]", "[In analysis]", ... prefix in bug title to be able to have an overview of the bugs progression.
Related
Stuck at a trivial problem in Grails 3.1.5: Show the fields of a domain object, excluding one of them, including a transient property. Yes, this is my first Grails 3 project after many years with previous versions.
The generated show.gsp contains
<f:display bean="rfaPdffile"/>
This will include a field that may contain megabytes of XML. It should never be shown interactively. The display: false constraint is no longer in the docs, and seems to be silenty ignored.
Next I tried explicitly naming the fields:
<f:with bean="rfaPdffile">
<f:display property='fileName'/>
<f:display property='pageCount'/>
...
</f:with>
This version suprisingly displays the values without any markup whatsoever. Changing display to field,
<f:with bean="rfaPdffile">
<f:field property='fileName'/>
<f:field property='pageCount'/>
...
</f:with>
sort of works, but shows editable values. So does f:all.
In addition I tried adding other attributes to f:display: properties (like in f:table), except (like in f:all). I note in passing that those two attributes have different syntax for similar purposes.
In the Field plugin docs my use case is explicitly mentioned as a design goal. I must have missed something obvious.
My aim is to quickly throw together a prototype gui, postponing the details until later. Clues are greatly appreciated
If I understood you correctly, you want to have all bean properties included in the gsp but the one with the "megabytes of XML" should not be displayed to the user?
If that is the case you can do:
f:with bean="beanName"
f:field property="firstPropertyName"
f:field property="secondPropertyName"
And the one you don't wish to display:
g:hiddenField name="propertyName" value="${beanName.propertyName?}"
f:with
So list all the properties as f:field or f:display and put the one you don't wish to display in a g:hiddenField Grails tag
You can also try:
f:field property="propertyName"
widget-hidden="true"
but the Label is not hidden in this case.
Hope it helps
My own answer: "use the force, read the source". The f:display tag has two rather obvious bugs. I will submit a pull request as soon as I can.
Bugs aside, the documentation does not mention that the plugin may pick up the "scaffold" static property from the domain, if it has one. Its value should be a map. Its "exclude" key may define a list of property names (List of String) to be excluded. This probably works already for the "f:all" tag; bug correction is needed for the "f:display" tag.
My subjective impression is that the fields plugin is in a tight spot. It is intertwined with the Grails architecture, making it sensitive to changes in Grails internals. It is also required by the standard scaffolding plugin, making it very visible. Thus it needs constant attention from maintainers, a position not to be envied. Even now conventions for default constraints seem to have changed somewhere between Grails 3.0.9 and 3.1.7.
Performance of the fields plugin is sensitive to the total number of plugins in the app where it is used. It searches all plugins dynamically for templates.
For the wish list I would prefer stricter tag naming. The main tags should be verbs. There are two main actions, show and edit. For each action there are two main variants, single bean or multiple beans.
My answer is that at present (2 March 2017) there is no answer. I have searched the Net high and low. For the index (list) and create and edit views, the fields plugin works well enough. A certain field can be easily excluded from the create and edit views, relatively easily from the list view (by listing those that should show), and in no way I could find from the show view. This is such a common need that one would suspect it will be addressed soon. Also, easily showing derived values in the show view, like 'total' for an invoice. One can do that by adding an ordered list with a list item showing the value below the generated ordered list of values, but that is kind of a hack.
In some ways, the old way was easier. Yes, it generated long views, but they were generated and didn't have to be done by the programmer - just custom touches here and there.
This is probably obvious to any seasoned bugzilla user, but using the UI, how do I see all the bugs I have fixed?
I have looked in the search window, and there are lots of variables i can select from but nothing like resolved_by or similar.
Seems like there's at least three things original poster might want to search for:
All bugs RESOLVED by OP as the resolving user.
All bugs RESOLVED by anyone while OP was the Assignee.
All bugs presently RESOLVED/VERIFIED/CLOSED (by anyone) on which OP is presently the Assignee.
Bugzilla appears to not have a "resolved by" or "resolver" Custom Search term, but in 4.0.7 and hopefully the latest, 5.0.3, you can express the following in "Advanced | Custom Search":
"Status" "changed by" "your_user_name" along with other boolean entries to limit it to currently RESOLVED/VERIFIED/CLOSED bugs and so on. That seems preferable to the accepted answer submitted by Fernando Oliveira, because it will only return bugs where OP was actually the user who changed the status.
Click on "Simple Search", then select "Closed" status and click on "Search"
I'm writing a GStreamer application and I use GST_DEBUG_OBJECT() calls and alike all around my code. In some cases it produces output like this:
0:01:05.049031594 2014 UNDEFINED segment DEBUG ...
which would be good enough for my purposes. In other cases it decides to output the segment information like so:
0:01:57.617158397 2014 default segment start=4294967297, stop=0, last_stop=0, duration=13586288, rate=0.000000, applied_rate=0.000000, flags=0x00, time=0:00:00.000000000, accum=38:50:00.111740672 DEBUG ...
So, my question is where from it gets this 'default segment' information and how to control it?
So far what it prints is some bogus data and what I want is either eliminate this 'default segment' info completely or at least show some useful info from the actual segment. I went through documentation several times and even looked at the code, but couldn't find much myself.
I'm working with a custom build of GStreamer for an embedded device running Linux and I wonder if this is controlled via parameters of the build?
Any help is appreciated.
I think this page will help you: http://docs.gstreamer.com/display/GstSDK/Basic+tutorial+11%3A+Debugging+tools
Basically you'll define your own debug category with the following (all from the "Adding your own debug information" section):
GST_DEBUG_CATEGORY_STATIC (my_category);
#define GST_CAT_DEFAULT my_category
And then after you call gst_init(...) do this:
GST_DEBUG_CATEGORY_INIT (my_category, "my category name", 0, "Description of my category");
Once you do that you should see "my category name" instead of "UNDEFINED" or "default"...
This is for "standard" GStreamer, but it will hopefully also work for your custom build...
It has been stated that the google plus-one button works it's way up the dom hierarchy when it is looking for microdata to set the +snippets information for sharing (Jenny Murphy said this at Google+ +1 Button Snippet+ Problem ). Also, the documentation on the +Snippets site from google at https://developers.google.com/+/plugins/+1button/#plus-snippet states "If the page is annotated with schema.org microdata, the +Snippet will use the name, image, and description properties found on any schema.org type". However, it doesn't appear that this is truly the case in some conditions.
We have a test page at http://www.magnetstreet.com/stores/html/weddings/testPage.html where it is demonstrating a very simple product page which has been marked up with schema.org microdata. This page passes w3c validation and its microdata is parsed properly in Googles rich snippets testing tool. However, when the +1 button is clicked and you proceed to share it, the api is clearly ignoring the itemprops set inside the product tag. This can be seen by how "page title" is displayed instead of "product title" which is the itemprop name.
Does anyone see any obvious issues with this code?
I would like to note, if we only have microdata properties set on the Product div and within (no itemscope or itemtypes on any outer elements), then the button works as expected. However, We have data on much more complex pages that need the other microdata, so removing all other microdata besides the product is not a solution.
There is an ongoing discussion I'm having with Jenny Murphy about this at https://groups.google.com/forum/#!topic/google-plus-developers/MvuZtu8prTo . In short, currently the +1 button only looks at the outermost itemscope for the snippet information. If it doesn't find it there, it stops parsing through microdata and instead looks for other ways to gather snippet info.
In the discussion I linked to, I've described why I think this can be a problem and am hoping to start some good dialog about it.
A friend of mine is now building a web application with J2EE and Struts, and it's going to be prepared to display pages in several languages.
I was told that the best way to support a multi-language site is to use a properties file where you store all the strings of your pages, something like:
welcome.english = "Welcome!"
welcome.spanish = "¡Bienvenido!"
...
This solution is ok, but what happens if your site displays news or something like that (a blog)? I mean, content that is not static, that is updated often... The people that keep the site have to write every new entry in each supported language, and store each version of the entry in the database. The application loads only the entries in the user's chosen language.
How do you design the database to support this kind of implementation?
Thanks.
Warning: I'm not a java hacker, so YMMV but...
The problem with using a list of "properties" is that you need a lot of discipline. Every time you add a string that should be output to the user you will need to open your properties file, look to see if that string (or something roughly equivalent to it) is already in the file, and then go and add the new property if it isn't. On top of this, you'd have to hope the properties file was fairly human readable / editable if you wanted to give it to an external translation team to deal with.
The database based approach is useful for all your database based content. Ideally you want to make it easy to tie pieces of content together with their translations. It only really falls down for all the places you may want to output something that isn't out of a database (error messages etc.).
One fairly old technology which we find still works really well, is to use gettext. Gettext or some variant seems to be available for most languages and platforms. The basic premise is that you wrap your output in a special function call like so:
echo _("Please do not press this button again");
Then running the gettext tools over your source code will extract all the instances wrapped like that into a "po" file. This will contain entries such as:
#: myfolder/my.source:239
msgid "Please do not press this button again"
msgstr ""
And you can add your translation to the appropriate place:
#: myfolder/my.source:239
msgid "Please do not press this button again"
msgstr "s’il vous plaît ne pas appuyer sur le bouton ci-dessous à nouveau"
Subsequent runs of the gettext tools simply update your po files. You don't even need to extract the po file from your source. If you know you may want to translate your site down the line, then you can just use the format shown above (the underscored function) with all your output. If you don't provide a po file it will just return whatever you put in the quotes. gettext is designed to work with locales so the users locale is used to retrieve the appropriate po file. This makes it really easy to add new translations.
Gettext Pros
Doesn't get in your way while coding
Very easy to add translations
PO files can be compiled down for speed
There are libraries available for most languages / platforms
There are good cross platform tools for dealing with translations. It is actually possible to get your translation team set up with a tool such as poEdit to make it very easy for them to manage translation projects
Gettext Cons
Solves your site "furniture" needs, but you would usually still want a database based approach for your database driven content
For more info on gettext see this wikipedia page
They way I have designed the database before is to have an News-table containing basic info like NewsID (int), NewsPubDate (datetime), NewsAuthor (varchar/int) and then have a linked table NewsText that has these columns: NewsID(int), NewsText(text), NewsLanguageID(int). And at last you have a Language-table that has LanguageID(int) and LanguageName(varchar).
Then, when you want to show your users the news-page you do:
SELECT NewsText FROM News INNER JOIN NewsText ON News.NewsID = NewsText.NewsID
WHERE NewsText.NewsLanguageID = <<Session["UserLanguageID"]>>
That Session-bit is a local variable where you store the users language when they log in or enters the site for the first time.
Java web applications support internationalization using the java standard tag library.
You've really got 2 problems. Static content and dynamic content.
for static content you can use jstl. It uses java ResourceBundles to accomplish this. I managed to get a Databased backed bundle working with the help of this site.
The second problem is dynamic content.
To solve this problem you'll need to store the data so that you can retrieve different translations based on the user's Locale. (Locale includes Country and Language).
It's not trivial, but it is something you can do with a little planning up front.
#Auron
thats what we apply it to. Our apps are all PHP, but gettext has a long heritage.
Looks like there is a good Java implementation
Tag libraries are fine if you're using JSP, but you can also achieve I18N using a template-based technology such as FreeMarker.