I know it's certainly a naive question but I couldn't figure out the answer by reading the scattered (and sometimes outdated docs) so I'm a bit confused. What's the conceptual meaning of all these view layer components and what's the difference between them? When should I use which?
I'd really appreciate if someone could shed a light on this. TIA,
A view is a basic component; it adapts a context and the request, so this component can apply data from the request and the context to produce.. something.
A page is a specialized view; it produces output aimed at the browser. It usually involves a template.
A viewlet and viewlet manager are closely tied together. A viewlet is a specialized view that is not meant to be used on it's own but is used in an assembly. The viewlet manager does the assembling here; you ask a viewlet manager for all the viewlets that are registered with that manager and are active. Viewlets are usually things like the login link, the personal information bar for logged-in users, etc. The login link would only be active if there is no logged in user, the personal bar only active if there is a logged in user, etc.
Basically, viewlets let you delegate the responsibility of a certain 'area' of rendered pages to components, where a manager handles one specific area and viewlets are the components that are used to render the snippets.
Related
I have been learning coding for about a month now. I have some good experience with Python, and additionally I have completed this web development course on Udacity.
Now, I have a good foundation for programming, but one thing that confused me a lot is how to interact with various websites and APIs. The course I did briefly touched on this in terms of XML and JSON files and how some webpages offer their pages in these formats for easier reading by other machines.
But there are still a bunch of tasks which I have no idea how to approach whatsoever, but want to eventually do. I have constructed some hypothetical examples for the purpose of this question. I will post my current rough understanding of how I would do them below each one, and would appreciate feedback (on the API interaction, not on the front-end or on any back-end algorithms/AI/parsing):
Creating a phone application (disregarding the front-end part) which can then communicate with and perform rudimentary tasks on my computer.
I have no idea how to do this, and my guess would be that I would have to look into some external application/API meant for this process and implement this on both-ends of the system.
Being able to write a bot which goes on to a game website and controls the object via script. (e.g going onto a pacman game website written in flash and automatically controlling the character to avoid the ghosts)
I don't even know if this is possible, or how browser flash games interact handle the user-server interaction. Would I have to post some data via HTTP manually in the same way that playing in the keyboard would do? Or is everything done client side, in which case how would I fake user input? How would I get information on the ghost's position to work the AI?
Creating a mobile app for my school by allowing users to put their username and password into the app and then having the app automatically log in to the school and fetch certain data (e.g timetable) and return back in a readable form.
I'm guessing that I would take the input from the user on my mobile-app, and then navigate to the school's login page and POST this data in the relevant forms to log in. And then that I would (somehow, not sure), navigate to the timetable URL through my code while still managing to stay logged in, and then parse the html there?
I would appreciate some detail on how these kind of things are done, preferably with reference to these examples, so that I can get a better conceptual understanding.
Thanks!
Note: I have asked all those various questions mostly rhetorically, just so that those reading can get a better understanding of what my current programming level and understanding of APIs is at. I do not expect nor require specific answers for each and every question (so I hope this doesn't get flagged as being too vague or requiring too much detail!), I just would appreciate some responses telling me roughly how each of these APIs work approximately and how I would even start at looking at how to do these things.
You asked too many questions and honestly speaking I am not able to read and grasp entire text posted by you.
So, I am focusing only the title of your question:
"A conceptual understanding of API"
API (Application Programming Interface) means a set of functions which you can directly use by simply passing parameters to them.
Actually, in application development there are many common functions which every application programmer have to use. So, instead of coding them every time by every programmer, they are already coded in functions which you can use simply by passing parameters to them (if they need any external parameter).
Example:
I am offering you a maths API, set of functions {add, sub, mul, div}. You can pass two numbers to any of these four functions and get desired result instead of coding every time for ever operation like add, sub, mul and div.
Hope it helps...
I have read there are good design patterns that resolve the following conflicting requirements: 1.) A domain model (DM) shouldn't be dependent on other layers like the UI and data persistence layers. 2.) The DM needs to interact with the UI and data persistence layers. What patterns resolve this conflict?
I'm not sure if you can call it a design pattern or not, but I believe that what you are looking for is the Dependency Inversion Principle (DIP).
The principle states that:
A. High-level modules should not depend on low-level modules. Both
should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on
abstractions. - Wikipedia
When you apply this principle to the traditionnal Layered Architecture, you end up pretty much with the widely adopted Onion/Hexagonnal/Port & Adapters/etc.... architecture.
For instance, instead of the traditionnal Presentation -> Application -> Domain -> Infrastructure where the domain depends on infrastructure details you inverse the dependency and make the Infrastructure layer depend on an interface defined in the Domain layer. This allows the domain to depend on nothing else but itself.
The DM needs to interact with the UI
About that, I cannot see any scenario where the domain should be aware of the UI.
This all really comes down to the use case of the software project. Use cases do not specify any sort of implementation in a project. You can do whatever you want, as long as you meet these specific project requirements.
There are fundamental building blocks that are necessary to meet these project requirements. For example, you cannot print a business report with last year's pencil taxes without having the actual number to print. You need that data, no matter what.
Then databases become the next level of implementation. Everything in the database is a fundamental building block that is required to complete the use case. You just simply cannot complete the use cases without it.
We don't want our users to just have a command line SQL program and do all the use cases by that, because that would take forever. Imagine every user having to know and understand the domain model behind your software, just to figure out what value to read to determine the font color of your title screen. Nobody is going to buy your software.
We may need more than a simply domain model to satisfy the use case from our customer. Let's build a program that will serve as a tool for the user to access the data, and update the data. We can simplify the knowledge and time required to perform this use case. For example, we can just make a button that loads the screen.
While the model, view, and controller are all viewed as being right next to each other on all the diagrams we see, they really belong stacked on top of each other. You can have a database without a view or a controller, but not vice versa. To build a view or controller, you must know what you are interacting with. You still need the fundamental pieces of data required to accomplish the purpose (which, you can find in the database).
I'm trying to make an architectural decision and I'm worried that I'm missing something big about URL routing / mapping when it comes to designing a basic REST API / framework.
Creating routing classes and such that is typically seen in REST API frameworks, that require one to manually map a URL to a class, and a class method (action), kind of seems like a failure to encapsulate the problem. When this can all be determed by parsing the URL dynamically and having an automatic router or front page controller.
GET https://api.example.com/companies/
Collection resource that gets a list of all companies.
GET https://api.example.com/companies/1
Fetches a single company by ID.
Which all seems to follow the template:https://api.example.com/<controller>/<parameter>/
Benefit 1: URL Decoupling and Abstraction
I assume one of the on paper benefits of having a typical routing class, is that you can decouple or abstract a URL from a resource / physical class. So you could have arbitrary URL's like GET https://api.example.com/poo/ instead of GET https://api.example.com/companies/ that fetches all the companies if you felt like it.
But in almost every example and use-case I've seen, the desire is to have a URL that matches the desired controller, action and parameters, 1 : 1.
Another possible benefit, is that collection resources within a resource, or nested resources, might be easier to achieve with URL mapping and typical routers. For example:
GET https://api.example.com/companies/1/users/
OR
GET https://api.example.com/companies/1/users/1/
Could be quite challenging to come up with a paradigm that can dynamically parse this to know what controller to call in order to get the data, what parameters to use, and where to use them. But I think I have come up with a standard way that could make this work dynamically.
Whereas manually mapping this would be easy.
I could just re-route GET https://api.example.com/companies/1/users/ to the users controller instead of the companies controller, bypassing it, and just set the parameter "1" to be the company id for the WHERE clause.
Benefit 1.1: No Ties to Physical Paths
An addendum to benefit 1, would be that a developer could completely change the URL scheme and folder structure, without affecting the API, because everything is mapped abstractly. If I choose to move files, folders, classes, or rename them, it should just be a matter of changing the mapping / routing.
But still don't really get this benefit either, because even if you had to move your entire API to another location, a trivial change in .htaccess with fix this immediately.
So this:
GET https://api.example.com/companies/
TO
GET https://api.example.com/v1/companies/
Would not impact code, even in the slightest. Even with a dynamic router.
Benefit 2: Control Over What Functionality is Exposed
Another benefit I imagine a typical router class gives you, over a dynamic router that just interprets and parses the URL, is control over exactly what functionality you want to expose to the API consumer. If you just do everything dynamically, you're kind of dropping your pants, automatically giving your consumer access to the entire system.
I see this as a possible benefit for the dynamic router, as you wouldn't then have to manually define and map all your routes to resources. It's all there, automatically. To solve the exposure problem, I would probably do the opposite by defining a blacklist of what functionality the API consumer shouldn't be allowed to use. I might be more time effective, defining a blacklist, then defining each and every usable resource with mapping. Then again, it's riskier too I suppose. You could even do a whitelist... which is similar to a typical router, but you wouldn't need any extended logic at all. It's just a list of URL's that the system would check, before passing the URL to the dynamic router. Or it could just be a private property of the dynamic router class.
Benefit 3: When HTTP Methods Don't Quite Fit the Bill
One case where I see a typical routers shining, is where you need to execute an action, that conflicts with an existing resource. Let me explain.
Say you want to authenticate a user, by running the login function within your user class. But now, you can't execute POST https://api.example.com/users/ with credentials, because that is reserved for adding a new user. Instead, you need to somehow run the login method in your user class. You don't want to use POST https://api.example.com/users/login/ either, because then you're using verbs other than the HTTP methods. However, with a typical router, you can just map this directly, as said before. Easy.
url => "https://api.example.com/tenant/"
Controller => "users"
Action => "login"
Params => "api_key, api_secret"
But, once again, I see an plausible alternative. I could just create another controller, called login or tenant, that instantiates my user controller, and runs the login function. So a consumer could just POST https://api.example.com/tenant/, with credentials, and blam. Authentication.
Although, to get this alternative to work, I would have to physically create another controller, when with a URL mapper, I wouldn't need to. But this seperation of concerns, functionality and resources, is quite nice too. But, maybe that's the main trade off, would you rather just define a URL route, or have to create new classes for each nuance you encounter?
What am I not seeing, or understanding? Am I missing a core concept here and just ignorant? Are there more benefits to having typical URL mapping and routing classes and functionality, that I'm just not aware of, or have I pretty much got this?
A lot of the benefits to routing you describe are correct, and some of what you say about physical mappings is also true. I'd like to throw in some experience / practical information that colored my opinion on routers over the last few years.
first of all, the dynamic parsing of url works well (most of the time) when you architect your application according to the MVC design pattern. For example, I once built a very large application using Kohana, which is a hierarchical MVC framework, which allows you to extend controllers and models for the sake of making nested urls. In general, this makes a lot of sense. But there were a lot of times where it simply didn't make much sense to go build a whole class and model system around the need for one-off URLs to make the application more functional. But there are also times where MVC is not the design pattern you're using, and thus it is not the defining feature of your API, and routing is beautiful in this scenario. One could easily see this issue at work by playing with frameworks that have a lot of structural freedom, such as Slim framework or Express.js.
more often than people think, a fully functional API will have an element of RPC-ness to it in addition to the primarily RESTful endpoints available for consumption. And not only do those additional functionalities make more sense as a consumer when they're decorating existing resource method mappings. This tends to happen after you've built out most of your application and covered most of your bases, and then you realize that there are a couple little features you'd like to add in relation to a resource that isn't doesn't cleanly fit into the CREATE / READ / UPDATE / DELETE categories. you'll know it when you see it.
it really can not be understated, it is much safer to not go hacking on the actual structure of the controllers and models, adding, removing, changing, things for the sole purpose of adding an endpoint that isn't inherently following the same rules of the other controller methods (API endpoints).
another very important thing is that your API endpoints are actually more maleable than we often realize. What I mean is, you can be OK with the structure of your endpoints on monday, and then on friday,you get this task sent down from above saying you need to change all of these API calls to be of some other structure, and thats fine. but if you have a large application, this requires a very, very significant amount of file renaming, class renaming, linkages, and all sorts of very breakable code when the framework you're using has strict rules for class naming, file naming, physical file path structure and stuff like that...just imagine, changing a class name to make it work with the new structure, and now you've got to go hunt down every line of code that instantiated the old class, and change it. Furthermore, in that scenario, it could be said that the problem is that your code is tightly coupled with the url structure of your API, and that is not very maintainable should your url needs change.
Either way, you really ought to decide whats best for the particular application. but the more you use routers, the more you'll see why they're so useful.
BDD is an "outside-in" methodology, which as I understand it, means you start with what you know. You write your stories and scenarios, and then implement the outermost domain objects, moving "inwards" and "deliberately" discovering collaborators as you go--down through service layers, domain layers, etc. For a collaborator that doesn't exist yet, you mock it (or "fake it") until you make it. (I'm stealing some of these terms straight from Dan North and Kent Beck).
So, how does a UI fit into this?
Borrowing from one of North's blog entries, he rewrites this:
Given an unauthenticated user
When the user tries to navigate to the welcome page
Then they should be redirected to the login page
When the user enters a valid name in the Name field
And the user enters the corresponding password in the Password field
And the user presses the Login button
Then they should be directed to the welcome page
into this:
Given an unauthenticated user
When the user tries to access a restricted asset
Then they should be directed to a login page
When the user submits valid credentials
Then they should be redirected back to the restricted content
He does this to eliminate language from non-relevant domains, one of which is the UI ("Name field", "Password field", "Login button"). Now the UI can change and the story (or rather, the story's intent) doesn't break.
So when I write the implementation for this story, do I use the UI or not? Is it better to fire up a browser and execute "the user submits valid credentials" via a Selenium test, or to connect to the underlying implementation directly (such as an authentication service)? BTW, I'm using jBehave as my BDD framework, but it could just as easily be Cucumber, rSpec, or a number of others.
I tend not to test UI in an automated fashion, and I'm cautious of GUI automation tools like Selenium because I think the tests (1) can be overly brittle and (2) get run where the cost of execution is the greatest. So my inclination is to manually test the UI for aesthetics and usability and leave the business logic to lower, more easily automatible layers. (And possibly layers less likely to change.)
But I'm open to being converted on this. So, is BDD for UI or not?
PS. I have read all the posts on SO I could find on this topic, and none really address my question. This one gets closest, but I'm not talking about separating the UI into a separate story; rather, I'm talking about ignoring it entirely for the purposes of BDD.
Most people who use automated BDD tools use it at the UI layer. I've seen a few teams take it to the next layer down - the controller or presenter layer - because their UI changes too frequently. One team automated from the UI on their customer-facing site and from the controller on the admin site, since if something was broken they could easily fix it.
Mostly BDD is designed to help you have clear, unambiguous conversations with your stakeholders (or to help you discover the places where ambiguity still exists!) and carry the language into the code. The conversations are much more important than the tools.
If you use the language that the business use when writing your steps, and keep them at a high level as Dan suggests, they should be far less brittle and more easily maintainable. These scenarios aren't really tests; they're examples of how you're going to use the system, which you can use in conversation, and which give you tests as a nice by-product. Having the conversations around the examples is more important than the automation, whichever level you do it at.
I'd say, if your UI is stable, give automation a try, and if it doesn't work for you, either drop to a lower level or ensure you've got sufficient manual testing. If you're testing aesthetics anyway that will help (and never, ever use automation to test aesthetics!) If your UI is not stable, don't automate it - you're just adding commitment to something that you know is probably going to change, and automation in that case will make it harder.
I'm new to BDD myself, but I found the cuke4ninja site to help in this regard. What they suggest (my interpretation) is you have your step definitions which are high level and UI agnostic, that calls into a "workflow" class which groups the details like "click this button", "populate this field" into a method that captures the workflow under test, which calls into a "screen driver" class that handles the UI automation for that particular screen. That way all the UI automation code is abstracted away from the step definitions and are in a single location, and if the UI change, you just have to change the code in the "screen driver" instead of all multiple tests. Here is the relevant page where it is discussed.
What does the BDD is describing?
In teams following a Behaviour Driven Development (BDD), the Acceptance Criteria (aka Rules) should describe "what the system does" instead of "how the system does it".
So, where are the UI/UX details are captured in a team which is following BDD?
In teams using BDD, The User Interface (UI) and User Experience (UX) (buttons, clicks, animations, etc) layer details should not be included as an Acceptance Criteria (aka Rules) in text format, under a ticket (e.g. issued with a Software Ticketing Tool such as JIRA, GitLab, etc). Instead they should be included within the design screens (wireframes, user journey, individual screens etc). For example, text notes may be embedded on the design screens with annotations, or just as comments next to the screens.
I am part of a studentproject and we are to develop a product for a company using Java EE. As "lead architect" in the project I am responsible for composing a good design which should be flexible for further extensions.
Background info: We are to develop a website with a drag and drop GUI with possibilites to connect data sources with data manipulations to perform on that specific data. The GUI should be generic and possible to integrate with upcoming products. This means that we cannot code to an implementation in the presentation layer. Instead we will use an interface to define what kind of data manipulations that are possible for all kinds of products. However, each product might also sport product specific data manipulations (thus extending the interface with more methods).
The problem I have with the scenario above is that I dont see how we could pass on these "product specific data manipulations" to the GUI and say that, in addition to the generic interface, we also possess these data manipulation actions...
Now I had a discussion with some of the more experienced programmers from the company and they told me that there is a common solution to this problem - more specifically known as the "Observer pattern". They draw something like [1] on the whiteboard and explained that it would be possible to "register" to a third party (getApplicationContext) that in turn could convey our product specific interface. This is a common problem to get rid of those nasty circular dependencies, they explained.
I have now had a look on the observer pattern and how it works and I still dont really get how I am supposed to solve the design problem. Could someone possibly try to explain how it would turn out in my specific scenario? I have no real problem understanding how it works with "subjects" and "observers".
Here is an UML diagram of the design where we are using a reference of the specific product. This is what is undesirable and something we would like to get around.
(maybe I got this all wrong...)
I am sorry but I cant change the picture to the correct one as I am a new user... Here is a link to an updated UML diagram:
It seems what you are looking for is the Model View Controller design pattern. The Observer pattern is just a part of this design pattern. There is a short description for doing this with Java Servlets and JavaServer Pages from Java EE on the wikipedia article.