I have a basic question about Foundation5 setup, and associated publishing workflow. I'm on a learning curve towards creating a better local dev-to-publish workflow, so bear with me please...
Currently, I create F5 Compass projects; straightforward, but lacks programatic minification, concatenation, (CSS) cleaning, etc. LibSass projects, and a process like this, seem to readily offer these capabilities.
My question, essentially, if this is correct, and if not, how such capabilities can be added to a Compass project? I ask this simply because I have existing Compass projects under development that could use the aforementioned utilities and, also as mentioned, I want to build a better approach in general.
Conceivably, I could migrate existing Compass projects (local instances of ModX) to LibSass, but I'm sure this would come with complications.
Thanks in advance for your input.
Related
I have recently started learning about Alfresco Content Service.
I have some questions:
My understanding is that the standard way to add customization is to create AMP's.
Why create an amps for each customization instead of adding it directly to the configurations of ACS? Are there some benefits like not having to restart the service or something?
If apply_amps adds all custom amps to the alfresco server (.war files), won't there be a risk of customizations writing over each other?
E.g if two different amps change the same standard button in the share service.
I have found that there are 2 ways to add these customizations as well:
Add dependency to the pom file. (works only for .jar)
Actually compile the .amp and move it to the correct folder and run apply_amps.sh.
From the documentation it seems to my like AMP-files used to be the standard way of adding customization but that there have now been a move away from this in favor of using regular jar files and eventually in 7.1 and forward use JSON instead.
Yet other tutorials I find mentions things like "always use .amp". Which then seems strange if it contradicts the information on the official documentation.
Also I found something about adding amps through the share interface? Or must they always be added when building the server (.war)?
Could someone provide me with a thorough explanation of the best practice for applying customizations to the alfresco content service? Preferably with details regarding a live production setting.
Thanks for helping me make some of this clearer.
I'll try to give you helpful answers:
Making app packages (APMs or JARs) is much better than changing config manually. It's good for versioning, portability (TEST vs PROD or between projects), composition (you can add some addons witch are often very useful)... It is standard and good way how to build a web app.
About conflict of customizations, I'm not sure how it works. Is good practise always use own namespace for every AMP.
If AMPs write to the same file, result is always append (share-config-custom.xml can get be very big).
Problem about JARs and AMPs is simple. Old version of Alfresco supports more AMPs than JARs. Now it does not matter with way you use. Try to look inside these packages they look very similarly.
I never heard about adding AMPs through the share interface. Have you some source? Only thing which is similar is creating content model through Model manager (https://docs.alfresco.com/content-services/latest/tutorial/model/)
I use for PROD combination of AMPs and JARs. I have a lot of legacy code and addons in AMPs and new things in JARs. Alfresco work with them same...
When developing for Alfresco, are there any advantages to using the MMT over Integrated Deployment? Is there anything you can develop using one method, but not the other?
Browsing through Alfresco's SDK examples, I noticed many of them used integrated deployment, and the same went for all of the Share webscripts I saw on Google Code. Right now I'm just using the Integrated Deployment method, and everything seems to be working well, but I'm curious if I'm missing out on anything by not using the MMT.
Modules and integrated deployments are exactly the same in terms of code capabilities. The main difference is about distributing your customization: if you need/want to
provide your customizations to the external world or
reusing them across different projects or
port them to different Alfresco versions
then modules are the way to go, especially if you're not releasing the source code. The only downside of AMPs is that they write something in the DB but you currently can't uninstall them, even if there are some tricks you can try out.
I personally still prefer using AMPs as much as I can for my customization, leaving to embedded changes only stuff that can't go into an AMP (e.g. overriding original Alfresco files). The maven way also helps (and drives you a little) towards this practice.
I'm currently working on a PHP project using CodeIgniter as my framework. I took a look at a few templating systems I could probably use - Strogen's Templating System (currently used in PyroCMS - if I'm not wrong), Twig, Smarty etc.
But I have decided to go on my own to build one from scratch. Since I have experience dealing with Wordpress templates, I was thinking of creating something similar.
To give you a run down of how wordpress themes work - Wordpress has a set of functions (Theme functions) that help gather data. I was wondering if following the same would be a good idea for my project as well?
If I did create such template functions which I would be calling within my views, would it work against the MVC principles? And would it affect the performance in any way?
Well, with MVC, models do the db interactions, views display the data, and controllers are the go-between. If you created your "template functions" in the controllers, I suppose you would be complying with MVC. If you wanted to say, create a library or helpers to do the gathering of/manipulation of data, you would not be complying with MVC convention. AFAIK, it's a matter of preference which way you choose. As far as performance, you could use profiling to test which is better.
However, if your aim is to build a templating system for CI that is similar to WP just because you are familiar with the way WP templating works, I'd proffer that it would likely take you substantially less time to learn a new one than build your own. I'd also imagine it would take much less time to learn the new one than it did to learn the WP one.
Also, I think pyro uses a combination of Phil's templating and smarty, but not positive. Phil has a templating system available for CI here: https://github.com/philsturgeon/codeigniter-template May be worth checking out.
cheers.
Let's say I have a Visual Studio solution with a Web project, a BLL project, and a DAL project. I'm trying to follow the repository pattern keeping my SQL code in the DAL with an interface that is referenced by the BLL.
I have a handful of common solutions for things such as error handling, usage logging, and other things that can be considered utility functions (i.e. not in the business spec). I'm keeping these in a Common project.
Here are a few ideas I've had with regards to structuring the Common project...
Bundle SQL with logic in a given class
Create a layered solution within the Common project
Discard the Common project and put utility functions in with BLL/DAL
Is one of these ideas better/worse than the other? Does anyone have a better solution?
It's worth noting that these utility functions will be reused in a variety of other applications.
Instead of creating a Utilities project which will be used have you thought about creating something that can provide a service? You might want to look at Aspect Oriented Programming. Red flags went up when I saw you listing off your examples error handling, logging, etc. Those scream AOP.
But if you want to stick with your layout.
I think I would go with 2, assuming that means restructuring the utilities project to be more Cohesive.
I don't understand (please clarify and I will edit my post)
Bundle SQL with logic in a given class
As for:
Discard the Common project and put utility functions in with BLL/DAL
I would be against doing so. If this logic is truly going to be repeated there is no need to push it back into your projects. This will lead to duplicate code and increased maintenance.
Side Note:
Just as a lessons learned, the only way Utilities projects work, are if you are the only developer or it is well documented and well designed. Sometimes utilities are too programmer specific, or are written in a way that only benefits a particular coders style.
I have seen countless times people rework their infrastructure pulling out all kinds of utilities, only to see their utilities project never get used. Make sure the "utilities" you are creating are truly useful to other people.
Do you have one solution with the web application project, class libraries, database project and tests? Or, do you segment it into multiple solutions? Why?
I'm asking because we're trying to streamline this scenario for Visual Studio 2010 and I'd like to get input from the community on how you'd prefer to work.
I tend (but not always) to have one solution per job, but I import existings projects from other solutions, such as my WebControlLibrary where I keep common user controls and classes, etc.
My actual solution for the job I then tend to break down into the Web Application, Business Logic Layer, Data Access Layer and Entity Layer, i.e.:
Solution
...MyCompany.WebControlLibrary
...Project
...Project.BusinessLogic
...Project.DataAccess
...Project.Entities
...Project.Scripts
...Project.Testing
...Project.Deployment
If a project requires something such as a mobile device, I'll always put that in a new solution, but it may perhaps share some projects of the current solution, i.e.
MobileSolution
...MobileProject
...Project.Entities
...MobileProject.BusinessLogic
The more 'stuff' you have combined, the slower Visual Studios becomes at building. You can obviously stop certain projects building by default, but that's when you have to start creating your own build configurations. If you are going to be creating large applications, I'd suggest breaking down into multiple solutions. I find it much easier to flick between solutions that to keep changing build configurations.
Another option is that when you build your projects you can reference their DLLs. I prefer to import said projects into my solution as you never have to worry about referencing the creating build configuration i.e. selecting the DLL from the Debug or Release folder.
Stand alone libraries can be their own solutions. References for those libraries can be made into the project that you're working with. Related items like the web application, the test setups, and specific libraries such as data access or business rules can be setup as projects within one solution. It really all comes down to how much you want to break things out for resuability.
This depends a little on the job the project performs.
For ease of use it's simple to have a solution that just contains all the projects required. If it's a large solution this can hamper you later on when the IDE starts to get slow and build times rocket through the roof.
Let's say one of the projects is a library used by your company to take card payments and interface with 3d secure. You present you're own GUI page to take the details etc.
If you had numerous sites that all take card payments you would greatly benefit by having this project in a separate solution and referencing the compiled dll. Any changes you require you would need to open up the solution, make the change, build it, go to the solution you're working in and test it. Sounds like a pita and you find it's just simpler to have it all in one big solution. But then if you have this library in every solution and make a generic change to it you need to repeat that change through out.
So you just need to make a decision on wether you're developing a separate project in the same solution or something that might be used elsewhere. If you needed more functionality than the library provides you could implement a partial class in your project and extend the library in that way. Or perhaps a wrapper class will suffice. But then you know you're not affecting the other sites that use this library and you are keeping your solution smaller and more manageable with a smaller memory print during development.