I m trying to find the best way to build my UI based on whos logged in.
The scenario is, there are (at the moment) 2 types of user normal and super-user the super-user will normally see more controls than a normal user
I was gonna do some heavy inheritance, ie create by default SomeDialog or if super-user is logged instanciate SomeDialogSuper instead, however I have some concerns:
I find that with gwt-ext when doing a lot of inheritance you need to create a lot of panel when you are going to inject things at a later stage.
The multiple SomeDialog and then SomeDialogSuper sound like a bad idea and a nighthmare to maintain
Then I though well I could use some convention so I don't have to worry too much about which control is instantiate but I m not terribly sure how to do this
Any pointers ?
We store GUI layouts in XML "page" files stored on the server which makes requirements like yours easy to handle (use "normal_user.xml" or "superuser.xml"). The page files are marshaled into a tree of serializable factory/DTO instances that are used to create the actual widgets on the client side.
We have built a large HR portal on a framework that uses this approach. That framework is now open source. Have a look at GWT Portlets.
Use deferred binding.
http://code.google.com/support/bin/answer.py?answer=59657&topic=10211
Related
I'm new to flutter/dart and I'm trying to create a little application using a Clean Architecture design.
I read some blogs and several presentations of Uncle Bob's Clean Architecture before starting to code to get the most of it and now it's time to implement it.
I guess my application could be divided in 3 main features :
authentication
classes (get access to lessons/quizzes on specific subjects)
admin (manage user, create lessons etc..)
I started to implement the authentication feature following the clean pattern, that's to say with a domain, data and presentation layer and I guess I did it quite well. It's (almost) fully tested (I'm trying to do some TDD) and seems to work as I wanted.
Now comes the problem. I want to implement the classes feature. I wish it could be independent of the authentication but it's not the case... The classes feature need to get the authenticated user from the authentication feature. I searched a lot on the internet but I can't find how to implement Clean Architecture with multiple features that need to share some data.
So there are my 2 questions:
How to pass data from a feature to another ?
How to inject dependency in a feature that need data from another feature ? (I used get_it for the authentication feature and inject all dependencies in the main() method before building the app. Since it did not need any external data it worked well. Now it's seem not possible to do the same for the classes feature since it first needs to get some data from the authentication feature).
Thanks in advance for your answers.
Along with your 3 features you should add another called core and inside that folder you can add stuffs that need to be shared. It worked for me . Good luck
One option is if you instantiate classes after the user has already logged in, you can pass that data in as a constructor parameter.
More generally, Provider is probably the best dependency injection tool for flutter. If you "provide" the authentication class to the widget tree for the rest of the app, you can say at any point below it, Provider.of(context) to access it and any public field it has.
Hope you're still working on Flutter projects after that long time.
I've been fiddling around with Uncle Bob's Clean architecture, and I managed to implement it in Flutter few months ago.
It's perfect, it separates your code into components (modules if you're coming from a native Android development environment) and isolates your data sources, so if you want to change the way you make API requests for example, you'll only need to change the remote data source part in your app, and all your application should work as expected.
I have made a test app using Clean Architecture I just uploaded on github and added a humble readme that describes the basic architecture and components of the app, I'll work on written articles describing the code very soon.
For now you can access the repo from here
I'm trying to find an answer to this for some time now... My solution was to create some transformation methods in the model class. For example, I have an ProductModel in the home feature file (from where i can add products to the cart), and an ProductInOrderHistoryModel in the order history feature file. So in the ProductInOrderHistoryModel file I have a method called toProductModel that gets an instance of ProductInOrderHistoryModel and transform to a ProductModel. That way I can add a product to the cart directly from my history order page.
Probably it's not the best solution, and the Uncle Bom would be really mad at me. But it was how I manage to solve my problem...
I am currently looking at various i18n npm packages and most seem to insist that the translations are stored in a flat file, e.g. .json formatted file. My questions is whether this has a performance overhead that would be greater then storing the languages in a database, e.g. MongoDB.
For example, if I have 10,000 translations (we will assume that in this particular application only one language file will be needed at a time, i.e. most will be using the application in English and some users may want to set the application to use a different language.) then this will equate to approximately 200kb of data to download before the application can even start being used.
In a React application, a suggested design pattern is to load data using container components, that then pass data to 'dumb' child components. So, would it not make sense to also load translations in the same manner, i.e. group the translations into usage, or by component, so that the data is sent down the wire only when needed, say, from a call to MongoDB?
I would integrate it in your API. That means you can create e.g. a REST or GraphQL API, which handles this for you. In i18n, it is often reasonable to store the data in a hierarchy. This means you can split your translations in different categories (like pages) and simply request those translations, which you really need.
I really like the way of doing it in the react-starter-kit. In this example, you find how they handle it with a GraphQL API and only request those translations, which are really required for rendering the page. Hope this helps.
Important files of the i18n implementation of the react-starter-kit:
GraphQL Query: https://github.com/kriasoft/react-starter-kit/blob/feature/react-intl/src/data/queries/intl.js
Example component implementation: https://github.com/kriasoft/react-starter-kit/blob/feature/react-intl/src/components/Header/Header.js
Of course if you have this amount of translations, I would use a database for a better system usage (in the react starter kit, they use simple file storage which is not really usable with so many translations). A mongodb would be there my first choice, but maybe this is only my own preference of flexibility and own knowledge.
Obviously, you don't want each and every language to be loaded on the client. My understanding of the pattern you described is to use a container component to load the relevant language for the whole app on startup.
When a user switches language, your container will load the relevant language file from the server.
This should work just fine for a small/medium app but has a drawback : you'll need another request to the server after the JS code has loaded to load the i18n data.
Another way to solve this is to use code splitting (and possibly server side rendering) techniques which could allow this workflow :
Server builds a small bundle containing a portion of the i18n data
Client loads the rest of your app code and associated i18n data on demand, as the user navigates through your app
If not yet done having a look at https://react.i18next.com/ might be a good advice. It is based on i18next: learn once - translate everywhere.
Your code will look something like:
<div>{t('simpleContent')}</div>
<Trans i18nKey="userMessagesUnread" count={count}>
Hello <strong title={t('nameTitle')}>{{name}}</strong>, you have {{count}} unread message. <Link to="/msgs">Go to messages</Link>.
</Trans>
Comes with samples for:
- webpack
- cra
- expo.js
- next.js
- storybook integration
- razzle
- dat
- ...
https://github.com/i18next/react-i18next/tree/master/example
Beside that you should also consider workflow during development and later for your translators -> https://www.youtube.com/watch?v=9NOzJhgmyQE
I'm using version 8.0.858 of Enterprise Architect and I am hoping someone knows how to make an external requirement internal again.
I have searched thru the EA user guide, and this tells me how to make an internal requirement external, but is silent on how to reverse the process.
I have hundreds of requirements linked to Use Cases where the requirement is marked as external, but they shouldn't be as they each only relate to one Use Case.
Here's an example of what I'm talking about
This makes it difficult to get an overview of what the Use Case requires because when you click on an external requirement, the description does not show up in the textbox, and you have to double-click it to open in a separate window.
My only thought is to hack the database in Access, but I'd rather not if there is any UI functionality. That said, if you have know how to edit the database directly to achieve my goal, then that would be a valid solution too.
To my knowledge this isn't possible, for the reason #observer notes. External requirements are model elements in their own right and thus have far more information associated with them than internal requirements do.
External requirements (and other model elements) are stored in the t_objects table, while internal requirements are in t_objectrequires. Connectors are in t_connector.
I'd advise against trying to hack the database directly. Use the automation interface instead (it can be accessed from an in-EA script); look at the Element and ElementRequirement classes.
I'm developing a site in Symfony, and I'm not sure what the best way is to handle this scenario.
I'm creating a party bookings system. Anyone can go to my frontend app and submit a new booking. Once they're finished, they'll just get a confirmation screen, they can't edit it. Easy.
Only certain users will be able to get to the admin app (it might be secured simply by being on an intranet, but that's not important, just assume it will be only accessible by admin users). They'll be able to view the list of submitted bookings. Easy.
My problem is around code re-use when allowing admin users to edit existing bookings. When you do generate-module in Symfony, the generated module (which as a newbie I'm assuming is a good example of structuring things) creates the form as a partial. I've had to customize this form a lot for my usage (lots of Javascript, etc), so of course I want to re-use this code, to be able to load an existing booking into this form. But there doesn't seem to be a way to share this partial between the apps (I've seen people mention making a plugin...but this seems complicated for this use).
I considered using an IFrame to load the form from the frontend and just passing an "id" parameter to load it in edit mode, but this would mean that the edit mode is not secure - anyone could go to the form on the frontend and pass this parameter to edit a booking.
I also considered putting all of the form display code (HTML, Javascript, etc) in a method on the form object, but this doesn't seem very MVC - all of the display code is then in the form. But this is only because I'm thinking of the form in the same way as a model - is that right?
I feel like this should be a common situation. You can share models and forms between apps, why can't you share this common form display code too?
Thanks!
You should reconsider having 2 applications in the first place. Not only you run into the code reuse problem, but also i18n, testings and other issues. I find it much easier to have 1 application with different bunch of modules for frontend and backend users. You can configure security per module. You can have one sign in form for all users and redirect them to appropriate module based on their credentials.
You can reuse partials between modules inside the same application, but you seem to be talking about two different applications (frontend and backend) so as far as i know the only way is to copy & paste the partial from one application to the other...
I am in the process of building a website content management system for one of my clients. It's a highly customized system, so I cannot use any "of the shelve" solution.
I need to allow my client to add pages to the website on the fly. I have two options here:
(1) Create a database driven page in the format of www.mycompany.com/page.aspx?catID=5&pageID=3 (query the database with the category and page ID's, grab the data and show it on the page) - or -
(2) Allow the management system to create static pages, something like www.mycompany.com/company/aboutus.aspx and www.mycompany.com/company/company_history.aspx , etc.
I believe that, while the former is much easier to implement, the latter is a better both for the user AND for Google.
My questions are (finally): (1) Would you agree that the latter is a better solution, and (2) What is the best way to implement such a solution? Should I create and update each file using the FileSystem (i.e. - the site's management system requires the user to supply a page/file name, page title and content, and creates the page on the fly based on these parameters)? Is there a better way?
Thank you!
It's entirely possible to have database driven pages with nice URLs. StackOverflow itself is a great example - this question's URL is http://stackoverflow.com/questions/1119274/adding-pages-on-the-fly-with-a-cms-system, but the page is built from the database, not static HTML.
I would use the first solution, but mask the addresses using a custom request handler. Basically, give each of your pages a unique string ID (such as about-us) and then, with your request handler that takes all requests, find this particular page in the database and render it.
See this article for some additional info (found it when googling for custom http handlers in ASP.NET.) In that article, it has the following handler added:
<add verb="*" path="*.piechart" type="PieChartHandler"/>
You would probably want to catch all paths (*), excluding certain media paths used for CSS, images and JavaScript.
More resources:
Custom HTTP Handler
HttpHandler in ASP.Net
I'd stay clear of static pages if I where you. Dynamic Data, MVC and some good planning should take you a long way!
What you need to do is to create some or many templates that each view/controller in mvc can use. Let whoever is responsible for the content handle it through dynamic data entities.
I would use the first idea, but work out a better URL scheme. If the system doesn't provide nice URLs (without ?), you'll have trouble getting the search engines to parse the whole site. Also using numbers instead of words make it hard on users to pass around URLs.
If you start to have performance problems you could add caching that would generate static pages from time to time. I would avoid doing that until you have to; caching can cause many headaches along the way to getting it right.
Although the existing advice is more-or-less sound, the commentators have failed to consider one factor which, admittedly, you haven't given much detail on. Are these pages that they'll edit once they're built, or a they one-shot creations? If the latter, your plan of generating static pages isn't quite so bad as they suggest. Why bother even having to think about database schemas and caching, when you can just serve flat content.
It will probably make for pretty lifeless, end-of-the-road pages, but if that's what you want ...