I'm trying to configure schema.org microdata in a job listing website.
My microdata passes validation without errors, however there is a warning, which I ideally would like to resolve.
For our application, Salary isn't relevant. It will never be included in the job listings, and it doesn't exist in our data models. However Google flags the following warning...
The baseSalary field is recommended. Please provide a value if
available.
Is there some way to indicate in the microdata, that a property has been intentionally excluded, so that it can pass validation cleanly?
It is a warning, not a requirement. If you want to make pass validation, you can use a dummy amount like £0.
Related
One of the things why really enjoy working with Breeze is because I have a lot of freedom regarding the metadata, and I use this freedom to manually provide an entity model, including validators. This works great, but when it comes to localizing the messages for the standard validators, I noticed that they use the property names instead of the display names, and this was because I set the display names after the metadata was loaded from server. Well, the thing is that I want to avoid a second call to server just to get the display names. As a temporary solution, I changed the breeze code to allow getting the displayName also from the metadata sent from server, but then again, I do not like changing the breeze sources.
Is there any other way of getting the metadata in one call and provide it to breeze? Naturally, other information like Description or Watermark would be welcome.
The latest versions provide a custom node, which I could use, but then I need some sort of interceptor for each property, where I take the display name and set it to the data and navigation properties. Is there a way to do this?
Remarks: I have a pull request on github for the breeze project, the changes are minimal.
Presumably you've read about Breeze's "custom" metadata support: http://www.breezejs.com/documentation/custom-metadata
If so, then all you need to do is create a custom endpoint on the server that creates json in the 'custom metadata' format (you will probably use reflection on the server to collect this data), and return this json to the client and then call
myMetadataStore.importMetadata(customMetadataFromServer, true);
So the general pattern for a RESTful API is to return a single object with embedded links you can use to retrieve related objects. But sometimes for convenience you want to pull back a whole chunk of the object graph at once.
For instance, let's say you have a store application with customers, orders, and returns. You want to display the personal information, all orders, and all returns, together, for customer ID 12345. (Presumably there's good reasons for not always returning orders and returns with customer personal information.)
The purely RESTful way to do this is something like:
GET /
returns a list of link templates, including one to query for customers
GET /customers/12345 (based on link template from /)
returns customer personal information
returns links to get this customer's orders and returns
GET /orders?customerId=12345 (from /customers/12345 response)
gets the orders for customer 12345
GET /returns?customerId=12345 (from /customers/12345 response)
gets the returns for customer 12345
But it'd be nice, once you have the customers URI, to be able to pull this all back in one query. Is there a best practice for this sort of convenience query, where you want to transclude some or all of the links instead of making multiple requests? I'm thinking something like:
GET /customers/12345?include=orders,returns
but if there's a way people are doing this out there I'd rather not just make something up.
(FWIW, I'm not building a store, so let's not quibble about whether these are the right objects for the model, or how you're going to drill down to the actual products, or whatever.)
Updated to add: It looks like in HAL speak these are called 'embedded resources', but in the examples shown, there doesn't seem to be any way to choose which resources to embed. I found one blog post suggesting something like what I described above, using embed as the query parameter:
GET /ticket/12?embed=customer.name,assigned_user
Is this a standard or semi-standard practice, or just something one blogger made up?
Being that the semantics of these types of parameters would have to be documented for each link relation that supported them and that this is more-or-less something you'd have to code to, I don't know that there's anything to gain by having a a standard way of expressing this. The URL structure is more likely to be driven by what's easiest or most prudent for the server to return rather than any particular standard or best practice.
That said, if you're looking for inspiration, you could check out what OData is doing with the $expand parameter and model your link relation from that. Keep in mind that you should still clearly define the contract of your relation, otherwise client programmers may see an OData-like convention and assume (wrongly) that your app is fully OData compliant and will behave like one.
I keep on finding myself wanting to add fields to CRM forms that don't actually represent physical fields on the entity. I want these fields to be sent in the Update message, for the benefit of my Plugins...
For example, imagine something like the out-of-the-box contact/address functionality. The main contact address is exposed as a set of fields on the Contact form. However, in actual fact there is some magic going on behind the scenes that causes an Address record to be created for the Contact containing the address details. I don't actually want to reproduce this, but it's a fair example...
Now, I know how to write a plugin that takes the address fields entered in the Create/Update message, and actually writes them into an Address object instead. That is simple enough. It seems the hard part is convincing CRM to display fields on the form for the user to enter the address data.
The only way I can see to do this is to create "fake" fields in the Contact-equivilent form, so that the form editor allows me to add the fields to the dialog. Then I have to filter these attributes out in a plugin, so the fake fields don't actually get written to the DB.
This would work, but involves filling the DB schema with fake columns that will (or should) never have any data in them. This makes future cusomisation of the system more confusing, as there are decoy fields called "DON'T USE - Address1" knocking around in all the GUIs. The problem gets worse when I need a fake Lookup field - this involves creating a fake relationship.
So: Is there a way to achieve the same thing without dumping fake garbage in the database schema?
Is there, perhaps, some way to create a form field for an arbitary attribute in Javascript on the form, such that the Attributes will be included in an Update message?
Sure, I realise I could IFrame or Silverlight something up to cater for this, but I'd rather use the genuine CRM form fields, and handle the data in the Update/Create message plugin hook.
Unfortunately, you have already mentioned the two options that I can think of: fake fields or custom IFrames.
I know it feels "dirty" but I actually haven't had much trouble doing the fake fields thing. Standardized naming conventions are your friend. I prefer fake fields over IFrames because users can still query and filter them in Advanced Find, reports, views, etc.
Just make sure they are readonly and make sure your plugins don't swallow exceptions - you want exceptions to bubble up and cancel the transaction instead of the possibility of the main record getting updated without the children.
I'm writing a small web application using Perl, HTML::Mason and Apache.
I've been using Mason's usual <%args> method for receiving 'normal' form parameters, and Apache2::Upload for receiving files.
However, I want to write a page that allows a user to upload multiple files, and I'd like to take advantage of HTML5's multiple attribute to input fields. This will look to the server as though there were multiple file inputs in the form with the same name.
The interface for Apache2::Upload doesn't seem to directly support this, allowing you instead to just get the data for a file with a particular parameter name. The documentation alludes to using APR::Request::Param::Table, but I can't find any documentation for doing that.
Please note that I'm not interested in answers that involve adding extra file input fields with different names. This is trivial to handle on the server, and my question doesn't involve front-end scripting at all.
Use the multiple attribute (in the form as you described) and then, after submission, call the Apache request object's upload method. That will give you a list of Apache2::Upload instances.
Good luck!
I'm currently using the Jira SOAP interface within a C# (I suppose the language used here isn't terribly important).
Basically, I'm creating an API and a Winform that wraps some of the functionality of the soap service so that our Devs can programmaticly add bugs when something goes wrong in our application.
As part of this, I need to know the custom field IDs that are in use in Jira, rather than hardcoding them (as they are still prone to the occasional change) I used the GetCustomFields() method in the jira-rpc api then filtered it, so that all the developer needs to know is the name of the field, then the ID is filled in for them automagically.
This all works fine, but with one quite important proviso: that you login to the SOAP/RPC service as a user with administrative privaliges.
The Jira documentation indicates that the soap/rpc service follows the usual workflows and security schemes, however I can't find anything anywhere that would appear to remove this restriction on enumerating custom fields (and quite why in any instance you would want someone to HAVE to be an administrator to gain this access, especially as the custom field id's tend to be in Jira's HTML source is beyond me)
Does anyone know if I've missed a setting somewhere? Or if there is some sort of work-around for this, short of hardcoding the custom field id's?
Or is this a case of having to delve in to Jira's RPC plugin and modifying the source for it in order to give me the functionality I require?
Cheers
Edit for the sake of google/posterity
Wow, all this time on, and it looks like Atlassian still haven't changed this behavior.
Worked around this by creating a custom dictionary that logs in as an administrative user, grabs the custom fields and then logs out. Not ideal, but it should work 'til atlassian change things
You're not missing anything - there's no way to get custom fields via standard SOAP API.
In JIRA Client, we learn about custom fields in two ways:
We download issues via RSS view of the issue navigator, or via XML representation of a specific issue. If a custom field is set for an issue, the XML will have its id, class and value (values).
From time to time we inspect the content of IssueNavigator search page - looking for searchers for the custom fields. Screen-scraping the HTML gives us not only ids of the custom fields but also possible values for enum fields.
This is hackery, of course, and it may go wrong, so a good API would have been a lot better.
In your case, I can suggest two solutions:
Create your own SOAP (or REST) remote API plugin that will give you just that info that you miss from the standard API. Since you're seemingly in control of your JIRA, you can install anything there.
Screen-scrape the "New Bug" page for the project and type of issue you need to submit. You'll get all the info - fields, options, default values, which field is required.