Alternative way to create ports in JointJs - jointjs

I have come across this page about creating ports in JoinsJS and it fits my needs:
https://resources.jointjs.com/tutorials/joint/tutorials/ports.html
However, it seems that this way got deprecated and the documentation offers no alternative solution. How can I achieve the same functionality in the new way?

I'm not sure it is deprecated,
you can see in their latest documentation https://resources.jointjs.com/docs/jointjs/v3.4/joint.html#shapes.devs
that it's not tagged as "deprecated" or "for backwards compatibility".

Related

Anyone know of a good "cookbook" for smartGWT?

I've done UI dev before, but not SmartGWT. Wanted to know if there is any such "cookbook" of best practices and "how-to's" - outside of the ShowCase that any of you would strongly recommend.
Thanks!
Alexx
The QuickStart Guide first: http://www.smartclient.com/releases/SmartGWT_Quick_Start_Guide.pdf
Definitely read cover to cover.
Then the public wiki has stuff for specific scenarios (eg how to set up JBoss with SmartGWT Messaging): wiki.smartclient.com

JIRA: Searching for all issues with a given link type

Is there a way to query for all issues with a particular link type?
For example, let there be a dependency link where an issue can "depends on" another issue. Is there a query to find all issues that depend on some other issue (aka. all issues with the "depends on" link)?
I know there is the linkedIssues (key, linkType) function that returns the key of all issues that have the linkType with the issue with key. I want to find all issues with a linkType with any issue.
Thanks!
You can use Script Runner plugin - Edit: It unfortunately is no longer free. The last version before 4.0 still is, though. Details here https://www.adaptavist.com/doco/display/SFJ/Downgrade+ScriptRunner
It sports a ton of incredibly useful functions, one of these is hasLinks()
Usage example:
issueFunction in hasLinks("blocks") OR issueFunction in hasLinks("is blocked by")
You can hack it with Craftware JQL's linkedIssuesFromFilter, where the filter would be "all issues"
The included function mentioned by Alexander is ideal for its purpose but if you want something more advanced check out the commercial JQL Tricks plugin: https://studio.plugins.atlassian.com/wiki/display/JQLT/Issue+Link+Functions
If you need a JIRA On-Demand solution - you might find this paid Add-On useful
It exposes MongoDB syntax and some conditions builder UI, so you should be able to search for the issues:
linkedIssuesHaveStatus([status])
subtasksHaveStatus([status])
linkType([linkType])
workBetween([started|created|updated], [from], [to])

Mark element as deprecated in XSD

I have an XSD that's going through a transition from one set of elements to another. During the transition, there'll be code expecting the new elements and code expecting the old elements. Therefore I need to keep the old elements in the XSD; I'm documenting them as deprecated (using free text in an xs:documentation element).
Is there a way of marking an element as deprecated such that a tool like xmllint will automatically warn if someone uses a deprecated element?
Create a new schema, with a new namespace. Call this "version 2". If you choose to support version 1 XSD and version 2 XSD in your application that's fine, but keep them seperate and don't try to layer the two on top of each other - especially if you're going try to stop people from using the version 1.
This is worth looking at as it describes some of what you're dealing with:
archive of http://www.pluralsight.com/community/blogs/tewald/archive/2006/04/19/22111.aspx
I realise, however, that doesn't really address your question. With regard to "is there a way to do this?" the answer is "no - not in a universally supported manner". I've seen people add their own doc annotations to give hints, but this isn't going to be universally understood by tooling.
Your best bet in the long run is to create come up with a versioning story for your schema(s) and keep version 2 seperate from version 1.

Using YUI and Prototype Together

I want to add a calendar control to a page that already includes Prototype and Scriptaculous. Not happy with any of the Prototype ones I could find, I'm considring using the YUI Calendar widget.
I this likely to cause any problems?
We have worked hard to make sure that YUI is safe to use with any other library. We namespace everything, as HermanD says, under only one required global (YAHOO) and one optional one (YAHOO_config). We don't modify native objects. And even though Protoype does modify native prototypes, we code defensively so that this doesn't break YUI functionality.
If you find any bugs in using the two together, please let us know.
Regards,
Eric
YUI Team
By default everything in YUI is within the YAHOO namespace, so as long as you sensibly apply namespaces to anything you use from YUI, I would have thought you should be ok.
See: http://developer.yahoo.com/yui/yahoo/
I successfully used the YUI tab control in an app I was already using Prototype and Scriptaculous in and had no problem. The weight of all that is a bit much though if you're looking at a publicly available app. I wouldn't care so much about an internal app, say for a company, but you might want to think about how much JavaScript you're making end users download and the number of separate files they're having to download for the page.

YUI Uploader 2.6.0 example

I'm trying to simply use some of the examples and instructions regarding the YUI-Uploader, and I'm being frustrated by a number of issues.
The "YUI Library: Uploader" cheat sheet's simple use case doesn't work for me because all the listed methods except addListener() do not exist on the myUploader object.
The example is for version 2.5.1 and includes a method called browse(), which not only was removed in version 2.6.0 but I cannot find any documentation for how to use the 2.5.1 version if I so choose.
I can't find the source FLA to the uploader.swf file so that I could theoretically diagnose all these issues.
Has anyone successfully used the 2.6.0 YUI Uploader, and if so is there some common interfering JavaScript I should avoid, or a better example to follow? Thank you.
Thanks for the replies.
I might note that I finished my "uploader" project before receiving any responses to this.
Part of my problems were due to some of the examples being for v2.5.1 and another part were due to not using an event listener to see when the component was ready. I got the most help from just dissecting what Flickr did.
You can find the source to uploader.swf here at Uploader.as now that the YUI source is available on GitHub.
You've got the wrong link for the simple example, here's the correct one.
YUI Uploader Simple Example
You could also take a look at my implementation if you'd like, it's pretty barebones and works fine using YUI 2.6.0.
Tivac.com YUI Uploader Implementation
It sounds like for #1 that you're trying to call methods on the uploader immediately. You should instead add listeners for all the events it can fire and do any configuration once the "contentReady" event fires. All the YUI examples & mine do that, so you can check there for a code sample.

Resources