i'm very new to jira and the abilities of customizing and setting up a project/role/group and so on are very confusing to me.
do you know if there is something like an overview how everything acts together, like an UML diagram?
I'd suggest to go to the admin workflow editor and have a look at those used in your projects (or the default workflow at first) in the graphical representation. There you can look at the transitions between the status and check their details.
You will notice conditions, validators and post-functions, if you want that level of detail you can check those in the standard workflow and see which fields are manipulated and/or checked.
This would be the closest to an UML diagram I could think of.
Other than that I suggest to simply create a test project, create test issues and use those like your company/department works. It will all fall together very quickly, especially if you do that together with people from all roles involved.
Related
I am a little ashamed for asking so many questions, but I really want to learn.
In Sipke's blog a webshop is created. There is one specific question that boggles my mind when trying to do something similar.
Let me spell out the basic requirements:
User registration form and login, etc. This one is covered by the blog and it works nice.
Creating product parts and so on. This one is covered and no problem there.
Ordering by filling in an order form and making the payment. See down
Having the order page maintainable by customer. See down.
Viewing your own orders and their status. See down
Maintaining customers and orders from backend system. This one is covered by the blog and I need to do some work there yet.
As for items regarding creating orders and viewing your orders. I have followed the approach for creating records and using standard MVC controllers. But then I encountered problems:
Menu for orders page. This I had to do manually after installing the module.
The order page itself. I had to create the view including title and so on. But I can imagine a customer wanting the order page on another menu and with a different title. And maybe add even some own content to the ordering page. This I couldn't achieve by using standard MVC approach. So maybe I am using the wrong approach here. So I was thinking about using contentparts for creating an order and displaying them and using the drivers and handlers for that. But before I go down that road and refactor everything I want to know if that is the right approach. A downside could be that once the module follows that route it can then not so easily be reused with customers that have other cms's capable of hosting an MVC3 module.
So when to use drivers, handlers and contentparts and when to use standard controllers and views.
You should use Drivers and Parts (with Handlers if needed) when you want to create functionality for content items. E.g. if you want to display a custom media with all products, you could create a Part (together with its Driver, etc.) to handle that. Read the docs on Parts.
If the functionality is not tied to content items the most possibly you want to use the standard MVC toolbox, it's fine. Look at the built-in modules how they do that. E.g. the Blog module uses controllers and views to show the admin UI, but has parts to enhance the functionality of for example the Blog content type.
To make things more complicated you can employ ad-hoc content items to build a page that you'd normally do with simple views, but that's an advanced topic :-).
Lot's (if not most) of the current Web frameworks provide an admin module for basic CRUD operations, but I find the ones I know usually very limited...
So, my question is, which Web framework out there provide the best administration backend?
By the best, I mean namely:
Domain objects that can be heavily polymorphic. Attributes/relations defined in a class appear when editing a record/instance of any of it's subclasses (and sub-subclasses, and sub-sub-subclasses, etc).
Abstract classes. It's ok to have abstract classes anywhere in the domain classes' hierarchy. Their attributes and relations also show in the records/instances of all descending classes.
Relations. Allow to edit (out-of-the-box) the records/instances that have many-to-many relations, and relations with associative classes (e.g., django calls these intermediate models)
Extension. Allow to extend the admin so that we can use our own "UI controls" for specific domain objects. Some information is just too "exquisite" for an out-of-the-box form-based control to work in a suitable way.
UI Components. Instead of having to choose between using all of it or none of it, it'd be nice to have generic "UI controls" that one could reuse from within any page of the website, to edit specific domain objects.
Programming language is not an issue at this point, although I lean towards the languages (or frameworks) that allow me to express the most information at the domain model level (and that the admin module can then use to give me a richer UI).
I've been playing with Active Admin and Rails Admin for a couple of Rails 3.1 projects I am working on. While both are nice, I've migrated more and more to Rails Admin. I've found it easy to customize, it does a very nice job with associated models, and has a great default UI.
Rails Admin
Definitely good old WebObjects with it rule system called DirectToWeb. It generates everything at runtime based on rules. By default it can display all your entity's properties and relationships.
I guess that every current web framework will offer something like scaffolding, but often times, the work begins as soon as you change your model.
Check out this post and this teaser about the latest DirectToWeb-based framework, ERModern. You use nearly zero code for what you see in the video and you can build entire applications around it. It was sponsored by the iTunes team.
Edit for your bullet points:
Abstract classes and domain objects that can be heavily polymorphic - You handle these using rules.
Editing relations - No problem, it only depends on the design of your components. If you use ERModern, you get this for free.
Generic UI components - This is exactly how DirectToWeb works. You use (or define your own) generic components that display themselves according to the current entity (an object inheriting from EOEnterpriseObject) and the rules that fired for the current state (the D2WContext, essentially a big dictionary).
You can see all of this in action in the 45 minutes long ERModern Intro Video.
This isn't an easy question to answer.
You never specify what language you want to use, and you named some features, but how much of these features do you want.
I mean I could suggest a number of frameworks and tools for ASP.Net MVC or Web Forms but what if you're a PHP developer or a Java developer?
I could suggest SharePoint (and I generally dislike sharepoint, but everything you want is in SharePoint), but then the question to ask is.
How much flexibility and freedom do you want to customize or how much do you want the framework to do and you just be a code monkey.
So I will give you just my opinion.
I use ASP.Net MVC for my custom apps. It does all of what you want and allows me the most freedom to create and extend with tools if I so to do so. Plus out of the box there's a user databse with roles I can easily create out of the boss once I run the app for the first time.
Also CRUD is completely easy and straight forward out of the box. just check it out http://www.asp.net/mvc there's a tutorial section that goes through what you're wanting that you could complete in half a day.
Then there are some OR/M like NHibernate, Entity Framework, Subsonic use www.google.com to find tutorials for these if you're not familiar with them.
Then there's SharePoint it has a learning curve but once you get past it it's pretty straight forward as it's easy to pinpoint bugs, focus on the business logic and not worry aobut data base schema (as you don't even need to touch a database).
I love WebObjects.
WebObjects -> EntityModeler -> Wonder -> ERD2WModernLook -> ERAttachment --> ERRest
Bam. Done.
One of the benefits of asp.net mvc is testing. Also multiple templates are available for views. I wonder, why not create some view engine for testing. It will allow to write tests declaratively (like vriting your markup, but adding assumptions and constraints). What do you think, is there any sense for that?
Made some investigations and see that currently poeple are using fake view engines to test their controllers. Here and here are 2 examples of this approach.
So in this context I`d say that idea of using views for testing purposes can be said like "Creating a view engine that will ease some default testing procedures".
By easing some testing procedures I assume the following:
Allow default checks, like checking for null, for equality or non equality to some types/objects.
Allow easy access to all things can be used to generate and fill a view. Its model, view data and so on. So that you can just write things like check model contain Customer and his name is John Smith or Products DropDownList has 5 products and allow to write this with some easy syntax. Like Model.Contains(Customer).CustomerName.Is("JohnSmith"), Model.Products.Contains(5). This is the one just came to my mind, I think there are better ways to write down test cases, that`s for sure, but I hope it gives the idea.
Allow to use Views that you already have to generate some tests using them. Would be great to have a kind of WebForms designer that allows you to generate parts of tests using parts of the view. I think this can boost the speed of test writing as you have enough context of what is going on and what need to be tested when see your View.
You might want to have a look at Fitnesse - see http://fitnesse.org. It is an acceptance testing framework that lets you put together acceptance tests in wiki form. This allows tests to be written, understood and executed by business users as well as by developers.
I am writing features with the same verbiage for some scenarios.
Feature: User Management
Scenario: Edit an existing user's details
Given a user exists
and
Feature: Group Management
Scenario: Add a user to a group's membership
Given a user exists
And a group exists
In SpecFlow is there a good way to define what step each feature calls? Am I going about this the wrong way with my scenario writing? Should I just bite the bullet and change my given statements to denote what feature they apply to? I'm new to BDD and SpecFlow so any help is appreciated.
The Gherkin format (that the tools in the Cucumber-family, like SpecFlow uses) does not have any structure for sharing steps between features (inside a feature, you can use backgrounds).
The meaning behind this is that the features should be self-describing and complete in their own. With using the Background section, you can avoid having too long scenarios, but still having all information together in the file. You have to repeat the shared steps for each feature, though.
As an alternative, you can also create event bindings (that is like "hooks" in cucumber), where you can implement some shard logic. But this shared logic has to be implemented in .NET then.
I'm working on an application in which we are trying hard to keep Separation of Concerns as strongly as possible. We're finding that the cross-cutting concern of security creates a number of complications.
However, it looks like these can be mitigated using attributes and Aspect-Oriented Programming.
I understand it as far as applying aspects to domain layer code, but what if you want to apply it to UI elements? For instance, what if I don't want to display a button when a user does not have permission to execute that functionality?
In our MVC application, at this point we'd have to write (pseudo-code follows):
<% if (user.CanSeeSomeData) { <%=Html.TextBox("MyTextBox") } %>
But we'd like to control the display with attributes a la AOP if possible.
Any ideas?
Also, if there are 3rd party, open-source tools that would be useful, those suggestions are welcome.
I'd say that a view shouldn't contain much programming (or nothing at all). The idea of using AOP (or a la AOP) in a place where the P is forbidden doesn't look nice.
Let's design it in a different way. Usually views have some control keywords to do the basic stuff: conditions and loops. More intelligence and I'd say that you're mixing the controller role there.
So the if (user.CanSeeSomeData) you put there, if it is in fact a simple flag. It's the way views should be.
When you were building the modelview object (the container where you put the information for the view). You could have used AOP to initialize/set that information with a nice attribute in that property for example.
You could ask for attributes instead of "ifs"
[UserCanSeeData]
<%=Html.TextBox("MyTextBox") %>
This looks like syntactic sugar, not real AOP. Any attempt to say that UserCanSeeData should have more than an if (like a database access to check user priviledges), is an attempt to move controller code into the view.