We are working on FHIR questionnaires and I wonder if there is already a library with definitions of FHIR questionnaires. I found GCS example https://www.hl7.org/fhir/questionnaire-example-gcs.html. Is there any place where I can find wider set of such definitions? If not, is it planned to be somehow created / maintained? I can see having such set published as something valuable for the community.
In theory, the registry that FHIR.org is standing up in the next few months could be extended to this purpose, but I'm not aware of that being in the near-term plans. And it's not something that exists yet. You could submit a change proposal (link at the bottom of each page in the spec) to ensure this idea gets formal consideration
Related
According to docs WM_PARENTNOTIFY seems to be deprecated, this sounds unusual but if this is the case then what API does replace it?
WM_PARENTNOTIFY message
It's not deprecated, you just happen to hit a bit outdated link.
The most recent I believe is this one.
You seem to have gotten confused by the disclaimer on this documentation entry. There are two parts to it:
We're no longer updating this content regularly.
This refers to the documentation itself. It got frozen at some point, when Microsoft decided to change their documentation site for the n-th time (with n > 3). Though it's probably the second part that had you confused:
Check the Microsoft Product Lifecycle for information about how this product, service, technology, or API is supported.
Since this documentation no longer receives updates, there's no promise made as to whether the content still applies. It could (and generally is) still accurate, but it could be wrong or outdated as well, and you would need to check elsewhere.
That elsewhere is here: WM_PARENTNOTIFY. It would certainly be nice to have the old documentation auto-redirect to the new content (and sometimes this works, too, easily identifiable by a query string that contains the redirectedfrom=MSDN parameter). If in doubt you can identify up-to-date documentation by an Edit link at the top right corner.
I'm developing a site for my company and I also need to modify the native component "mailto" to fit our needs.
I'm working with a joomla 2.5
I was wondering if future updates occur, what will happen to the lines I've added, for example, in "\components\com_mailto\controller.php"...
I haven't find answers on the net.
Also, for the same reason, I've modified the default layout of an article. Should I rename it? and if yes, how, because I couldn't do it (when I've tried the article did not display).
Thanks for your help
Before starting to edit core Joomla components, should should always have a look at the options you have. I don't believe in editing core file as it simply causes problems for updates when released, therefore in my opinion, you have 2 options:
I always make a note of all my requirements and start looking for a 3rd party extension that caters for my requirements.
If I cannot find a 3rd party extension and don't particularly want to start digging into it's code, I would go with developing a plugin. Plugins are used to manipulate the behavior or something and therefore come in extremely handy for when you would require core editing.
Editing the layout of an extension view is completely fine, but it's strongly recommended you make a Template Override so that if the extension does ever get updated, your changes won't get overridden.
So to answer you initial question, any line you have added to the controller.php file will get overridden when you decide to update the extension.
Hope this helps
While the answer from Lodder is totally valid, as a last resource you can also consider forking the com_mailto as a separate component.
This has some disadvantages:
you need to rename all the files involved (controllers, models, views)
you need to maintain it and keep in in sync with future updates (consider than you are now on 2.5.x and in a year you might want to upgrade to 3.x).
I use Trac to track my bugs related to my php web application. Tough, mainly I register feature request/tasks in trac. Do you find it a good practice, btw?
It's very handy, becouse I can track my tasks via Eclipse/mylyn, comment and fix them. I like trac very much, but I'm afraid of a lot of loosley coupuled tasks, that almost looks like bugs.
Is there a way (or other tracker system) to store my tasks hierarchically? I mean:
Store module (feature)
Add product (feature)
List product (feature)
Delete product (feature)
Unable to delete no name product (Bug)
Other Module.. etc.
Edit: Is there any other good practice where and how to store tasks hierarchically?
Fogbugz has tasks & subtasks, I haven't worked with this feature enough to see if it would help though. You could play around with the hosted eval version, though. (For my taste, the web interface feels to sluggish for me to use it - but I have that problem with lots of things.)
I recognize your problem as one of my own, however I'd prefer to use separate lists/hierarchies.
[update]
At the moment, I am using the starring and heavy search/filtering, and for "keeping my head on" with quickly incoming tasks or larger refactors, I use pen&paper for temporaries (A5 ringbound booklet) and ToDoList for semi-permanents.
JIRA also has this functionality + it's almost free ($10 for 10 users).
See here, and here.
And yes... I think this is good practice, just don't over exploit it.
And this is how it looks like:
You could stick with Trac and look for desired functionality in http://trac-hacks.org/
That looks like what you want (there might be others I just did a fast search):
http://trac-hacks.org/wiki/MasterTicketsPlugin
http://trac-hacks.org/wiki/TracTicketDepgraphPlugin
We are using a couple of plugins from http://trac-hacks.org/ with 0.11 and they work great.
Have a look at the Roundup Issue Tracker.
Years ago, before Trac came out, I wrote several user support and development trackers with it. It's very, very easy to customize the database schema and create new html page templates.
To manage hierarchic tasks, you basically define an IssueClass-based task class that way:
task = IssueClass(db, "task",
dependson=Multilink("task"), # here, you link tasks to other tasks
assignedto=Link("user"),
keyword=Multilink("keyword"),
priority=Link("priority"),
status=Link("status"))
There's a recipe in the Roundup documentation that shows you how to create "blockers" issues, meaning that you can't close an issue if one of its linked issues is not closed:
http://www.roundup-tracker.org/docs/customizing.html#blocking-issues-that-depend-on-other-issues
TargetProcess supports the hierachical structure you want. It's an agile Software Project Management Software, however it features highly customizable development processes and can therefore be used for Waterfall or Kanban/Lean processes also. The deepest hierachical structure you can have goes like this:
Program
Project
Release
Feature
User Story
Task
There is a free community edition which you can use for up to 5 users. TP has a lot more than just task tracking, it features Bug Tracking, Q&A, Help Desk, Time Tracking...
You mind look at GoPlan: http://goplanapp.com/.
It is fully functional project management web application, which provides to create a hierarchy of tasks. There is a free plan, so You can check it easily. You can have task tree with any depth.
Difference between this tool and Trac is that GoPlan is not directed to maintain source code, but a project itself, so You cannot close Your tickets from Eclipse. Unfortunately tasks do not have resolutions (tickets have, but they cannot be arranged in hierarchy), but I think it is not a kind of disadvantage that discourages from using this application.
You've probably already thought of this, but I'll put this in just in case. In Trac, I oftentimes organized tickets as sub-tasks, at least through convention by simply placing links to those tickets in the description of the master ticket. What's nice about this is that closed tickets are shown as crossed out, so you can get an idea of the status of the sub-tickets at a glance. OK, so it's not setting up a hierarchy, but it's a flexible system that also allows you to set up other relationships; for example you can also reference another ticket as a dependency or related issue.
Some of the requirement management tools out there support hierachies, e.g. CaliberRM from Borland. However, these are heavyweight and commercial. This only makes sense if you have some significant amount of information to handle.
I want to ask one of those broad questions so please go easy on me. I know that phil is doing well with pyrocms but I would like to use pyro for my sites and also know how to write custom additions to the cms to suit my needs so what bums me out is how do you use it? where do i add my additions? how is it laid out? Like I said before go easy with me cos there is no documentation for pyrocms.
Thanks
I suppose this is one for me then :-)
modules can be added to the system by adding the folder to application/modules and copying the folder structure. To understand the modular structure better read the documentation for Matchbox by Zacharius K. I'm on my iPhone on a train so not going to look I up for you :-)
look a details.XML within the module to see how to set frontend/backend module type and when you have set a module with is_backend_sidebar clear the cache (or wait 6 hours :-p).
Documentation WILL come soon, my Internet has been down 2 months longer than expected so finishing v0.9.8 then documenting the lot will take a while.
Tweet or email me for more help.
Someone on here recently recommended BWToolkit, and it really impressed me, so I started googling for more IB plug-ins. I've found a couple on random blogs, but haven't been able to find any kind of repository/aggregator for them. Anyone know where I can find more of these?
Thanks.
I just created a page on CocoaDev to list them [edit: question originally just said “Interface Builder plug-ins”, did not mention Cocoa frameworks], with the two I know of listed.
Well that's a good start. I guess that wiki page is the de-facto repository, for now. Seems like there's not much out there.
You are not looking for Interface Builder plug-ins. You think you are, but you aren't. BWToolkit, the example you use in your question, is not an Inteface Builder plug-in. Brandon bills it as an Interface Builder plug-in but it is actually a framework and a plug-in. The framework contains the actual controls. The plug-in contains the integration with Interface Builder.
So really, what you are looking for are frameworks that contain or provide Interface Builder plug-ins. I have changed your question to reflect that, so it is more likely to be found by people using Google to search for similar things in the future.
I know what I am looking for. Not all frameworks contain IB plugins. I am looking for a specific subset of frameworks, those which contain IB plugins. An IB-plugin without a framework is useless, therefore the framework part is assumed. I am NOT looking for regular old frameworks, so stop trying to change my question to that. Your additions only seem to be confusing people.
I have reported your post, hopefully moderators will be able to stop your obnoxious behavior.
"Without a framework, what would you have to plug in to IB?"
Your words, not mine. Anyways, I'm done arguing this with you. Just remember that I can roll back for every time that you edit.
It's clear you have a lot of experience in this field, but instead of offering answers you decided to nitpick where there are no nits to pick.
Additionally, you have not "changed the question to refelct that," you have changed the question to a completely different question. I would have though that after four rollbacks you would relaize that you're doing more harm than good. Just stop, okay?
Of course, Chris Hanson is absolutely correct when he says that an Interface Builder plugin is useless without an accompanying framework. Interface Builder merely provides a graphical way to manage objects in a framework; without the framework itself, Interface Builder has nothing to manage.
However, I do think that there is a completely valid sort of Interface Builder plugin that wouldn't necessitate the installation of an accompanying framework, and that would be one that provides Interface Builder integration features for objects in Cocoa/Cocoa Touch which would otherwise appear as just generic objects.
For those of you who come to this page Google, please recognise the difference between Interface Builder plugins and frameworks: even the examples mentioned above work on frameworks (they could be Foundation, AppKit, UIKIt, etc.)