Once an html page has been put together it starts to acquire dependencies on Angular and typescript.
This is not ideal for the web designer who really just wants to be able to view and modify their design. Usually this involves data elements too.
In our team the designer needs to be able to continue to work with html and stylesheets; they are not a separate contracted resource.
Is there a way to set up a project so that the web designer does not need to concern themselves with npm packages, Angular versions and data sources?
I have since had an idea...
As it happens I am a Linux user, the designer is a Mac user. I am wondering if it would be possible to create a project consisting of symlinks to html with typescript stubs.
A mock datasource might also be a viable solution.
Related
I work for a company that develops many websites to be used internally but many have parts that are public facing. It is important that all our sites look the same. In moving to dotnet core we found that we are no longer able to use a virtual directory to host the Layout page for our site.
We were storing our Layout page on a file share and referencing it in our projects with a virtual directory. This way if we needed to change the information in the footer, header, or some style/js we could upload a single change to the Layout page and that change would take place on all our sites.
I've tried researching any possible ways and the only thing I can come up with is a custom middleware that downloads the layout page from the file share and updates the current layout page if it is out of date.
.NET Core gives you the capability of creating Razor libraries. This would be a separate project where you can have shared views and reference it to the rest of your projects. You can find a simple implementation here.
You can choose one of these two options to do this.
Reference this project in each solution. Since your solutions directly reference the razor library, any change that is made in the common library will be reflected in every solution without the need of repacking and publish.
use dotnet pack to create a nuget in a shared location. While this option will require you to repack and publish each time, in some cases it would be a more organized solution. You can have a version setup. This means that when you update the shared razor project you will define a new version number. You can update this on each one of your solutions. This reduces the risk of a project breaking. Let's say you have 5 projects and 2 of them are not compatible with the latest update. In this case, you can update the 3 right away. The remaining 2 can be updated when you can spend time updating these projects to match the new requirements.
We have some JSP code to run in our pages.
There is a UI designer who will constantly update the UI but does not have Tomcat server. We prefer he doesn't because he isn't a programmer.
However, it is getting annoying to have to cut and paste the JSP related code each time he updates the UI.
Is there anyway to handle this issue? We prefer to keep the same files, but still have it so he can see his UI work without worrying about the JSP and when he checks in the new files, we don't have to cut and paste our JSP related code.
One example of such code, is that there are certain navigation menu items which are displayed depending on the user.
We are using Tomcat authentication. We could I suppose use AJAX to obtain the user information, but is that less secure? Everything else in the application is AJAX.
The problem here is that this person is not working with the team. Rather, he's creating work for them... and it goes both ways. Read on.
I both do and manage front end development. If this UI person was on my team, I would force him to set up a Tomcat server. He just needs to learn some things.
In effect, when implemented properly, JSP is not much different from any other server-side markup language for views, such as Rails + ERB, PHP, .NET etc... even Javascript templating engines (mustache, handlebars, etc.). The same condition checks, for-loops, auth checks - all basic view-layer logic that is needed is available and usable.
If he's on a Java project / team, he needs to learn the Java front-end. It's that simple.
His main tasks should be basic, and frankly, he shouldn't even need to install a Java IDE to do them. They are:
Get/push source code + analyze diffs (any source control client)
Build / deploy latest to his local environment (scripts or .bat files)
Work on the running app*
(*) The last part is where things get tricky. If you work directly on the running server and then accidentally run a fresh deploy before copying over your updates, you're screwed. If you use symlinks (which are also available in Windows), there may be files that only appear post-compilation, or locks, or sync issues when getting latest code - all creating problems.
The way I have found that works best is to work on the code repo location (pre-build), and create two scripts:
Build+deploy - stops running server, blows out directories and caches, builds latest, and redploys
Update - Synchronizes the View files and any other necessary directories with the deployment target. You must be sure to disable hot-deploy in the Tomcat config, or you'll get memory leak errors.
That said, and it should be obvious by now: Java is one of the most difficult ecosystems to develop UI's for. The compiled nature and complex environment requirements make development slow and tedious, with significant dependencies on different people or systems to make a decent product.
JSP itself, while capable as described above, is almost always organized badly, with various ways of includes, tagfiles, partials, frameworks - it becomes a UI person's worst nightmare. GSP (from Grails) solves a lot of the organizational issues, but will require flexibility from the dev team. Even then it is not an "ideal" solution.
JSP syntax - JSTL, C:tags, etc. creates even greater headaches. Front-end people who do not program, don't use IDE's and therefore don't have a way of looking up methods, objects, parameters etc. when writing or customizing conditional logic or loops. The dev team can help by pre-writing these out on the page, but any time there are changes or enhancements needed, it requires meetings, conversations, and compromise.
In the long run, you should abstract the Java app from a separate, more flexible, more capable front-end technology stack, using REST / JSON-based services to talk between the two. (Side note: For performance / apps with scale, ensure you are using either a custom protocol or Web Sockets).
My preference is node.js, because front-end developers can stick with the language they will know best: Javascript / JSON. But it could be anything that your particular front-enders are comfortable with and can do design with.
The key is to eliminate bottlenecks on both front-end and back end. Both tracks should be able to develop and iterate quickly, with the RESTFUL API being the key point of collaboration.
Lastly, for those of you who are aspiring front-end developers / designers but only know Java (or some other server-side technology), I CHALLENGE YOU to learn something new. User-facing technologies are in a constant state of change, and more recently that change has accelerated. If you want to have UI-competitive products, you need to invest in technologies that will make them competitive.
I am planning to create a HTML5 web application. I have a couple of queries though-:
I wished to know if it is possible to create a business oriented application using HTML5 only without a backbone like Asp.Net. I found a lot of articles on google suggesting the use of Asp.Net MVC, or ASP.Net website as a base template but none suggesting a HTML+js alone approach.
Given the web standards update for VS 2010 SP1 and js libraries like Modernizr, is it possible to create an app completely in HTML5 using Visual Studio.
You're eventually going to want to do some server side work, and for that you would need either Java, PHP, or ASP set up to intercept and process commands... you could go ahead and create everything in HTML+JS alone, and use the file writer for "permanent storage" but that's really cutting corners, and can lead to catastrophe down the line depending on where exactly you are trying to take this application of yours.
I wrote a prototype for my software in Python as a desktop client-server program, but I want to do the real version as a web service. (I have seen the light? much better deployment and reduced cost) Trouble is, I don't know web development.
I already did something webdev-ish: I have a page with a form on it, that when submitted Apache will run my Python script, which will do some server-side tasks and then send the result on a new page back to the user. Its a very simple tool (doesn't use any DB or framework), but I suppose that's the basic idea of web-based services... I think. To me that was a workaround, I did not realize it is webdev-ish.
So I have a basic idea of how it works, and about 8 years of programming behind me, but I need to learn:
How to design web sites (XHTML and CSS?)
Javascript and AJAX
More advanced features of databases (Postgresql)
I'm thinking Python/Django is a safe bet.
Any suggestions on where to start? I'm not the type who has the patience to read a book; I would rather jump in and build something simple first, then bigger and bigger stuff, but I can't seem to get my head around learning web design - I still format everything with tables.
Cheers and thanks
Check out Django. Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.
There will be a learning curve, but you might as well learn how to do it right the first time. Go through the documentation, and start building small Django applications. There are tutorials on the Django website.
And yes, you will have to learn HTML and CSS anyway.
Tables are not evil, by the way. You don't have to learn your first website with CSS, but you will need to learn correct CSS layout sooner rather than later. There are free CSS templates out there you can use, which makes the correct use of CSS much easier.
I only got slightly into Django, but I hear good things, so stick with it if you like the approach... inheritance & templating language
XHTML blocks just need to not overlap (markup container rule, good XML syntax with contained elements closing before new ones are begun). Honestly the simplest & most common approach to start web layout is PHP, so I suggest that as first alternative since it is so template-centric.
my favorite CMS is ZOPE, built and used with Python for scripting. Zope3 is more like Django, Zope2 I use more still (Python 2.4.x) has some internal syntaxes and methods to grapple with at first, but if you wish to try it I have a basic site editing framework.
the advantage is the object database hierarchy is just like site structure, inheritance of scripts, content objects (HTML chunks & contextual values), properties... so duplication is minimized, the whole site can be a simple template, reuse & extension maximized. navigation scripted, archive by month & listing contents scripted, footer once, sidebar inherited throughout site - override by cloning into subdirs and editing or specifying object/property for local instance closest to the URL path then seeking up to root.
users can have roles in sections, XML-RPC/HTTP/FTP all ZOPE methods including user-defined, so rich clients can workflow media effectively. batch process media uploads with default containers for each item and metadata (filename, type extension) so users get right to their details. ZOPE can host files or static, remote, whichever, so long as the app knows where to find them (one base property for the app or project root)
if you get into Django there is the ZODB standalone library part of ZOPE for persistent storage only, no ORB
The shop that I am working part time with is new to Microsoft CRM. I just want to survey what projects have developers done to the system to extend its capabilities.
I can break the work I did into four sections:
Tailoring - Simple field level changes. A lot of this is just making sure the fields and language suited the business I was developing for.
Customisation - More complex changes, generally needing JavaScript and maybe ASP.NET. Some examples would be to use an IFrame and pass values to it from a CRM form. The IFrame would then do interesting things like mapping, charting or give you buttons to do other things. For buttons I would often times use JavaScript to replace the outerHTML in the HTML dom of an IFRAME to show a button rather.
Integration - using .NET to connect MSCRM to other systems. Connected it to Great Plains, Speech Server, SCOM (was called MOM back then), custom LOB systems etc... One interesting one I did was to develop a SSIS component that wrote into MSCRM via the web services.
Reporting - Building reports. In reporting services and in Excel. Excel made for great dashboards because of the dynamic update nature of it.
I have a few (war) stories up at http://www.sadev.co.za/taxonomy/term/7 if you are interested.
I (and others) have implemented a LINQ query provider for the web service layer http://www.codeplex.com/LinqtoCRM.
I did some work with CRM 3.0. My work enhanced the program and turned it into a Document Management app, where you could scan and upload documents based on a case, contact, customer, vendor etc. The .NET SDK back then could have used a bit more work, but I hear with newer versions of CRM it has gotten better. CRM allows for attachments but not at all levels, more at the case level.
We extended 3.0 to send text messages rather than email. There are tools available (for 4.0 at least) to do that now, though.
We also extended it to push service appointments through to Exchange, as due to the workforce being mostly mobile they did not have the CRM client for Outlook.
Two other major areas of development not yet mentioned are plugins and custom workflow assemblies.
Plugins allow you to intercept many of the messages that CRM processes to insert custom logic. The possibilities this gives you are endless because you can intercept all kinds of messages including Create, Update, Delete, and even Read!
Custom workflow assemblies are assemblies that you register with CRM that integrate with CRM's workflow UI. Often times, they perform simple tasks that are useful when modifying form data. Other times, they are more complex like sending status reports.
Custom workflow assemblies are always listed beneath the native options. In the screenshot, everything below "Stop Workflow" was added via a custom workflow assembly.