Transitioning form Front-End to AEM Developer - Troubles with Components, Parsys & more!

The first thing I notice is that if that code you included is what you are using you aren't actually including the parsys. What you included was:

<div data-sly-resource="${@path='par', resourceType='/libs/foundation/components/text'}"></div>

What it should be is:

<div data-sly-resource="${@path='par', resourceType='/libs/foundation/components/parsys'}"></div>

The reason it highlights is that it's a text component not a parsys. My guess is in your first step the reason you weren't seeing any components is that you hadn't set up your par sys in design mode. See http://docs.adobe.com/docs/en/aem/6-0/author/page-authoring/default-components/designmode.html for details. 

I would focus on learning Sightly over JSP, but if you are looking to become more than a component developer you will need to learn Java and OSGI. I don't necessarily have book recommendation I can make. 

@Tyler.Maynard - in the same boat here, feel like almost breaking down and crying. However I would never fully transition to being an AEM dev, I got forced at the whim of a client. We're building a single-page-app with React components, so instead of just handing over static resources I somehow got forced to develop in AEM to ensure the author experience is desirable.

My critiques: 
    - So my options are to use Brackets, Eclipse or CRXDE? I guess I could figure out Vault instead? Drives me bonkers, I want to use vim and the abstraction of the filesystem with no good open source resources to mitigate it is causing huge pains in my developer workflow.  How am I suppose to use GIT? This whole framework doesn't feel right for frontend development. They need to figure out a way to totally sandbox the frontend from all Sling filesystem abstraction.
    - Why can't someone at Adobe get Sightly(HTL) to be a fully functioning standalone template engine, make an npm package compatible with Express/Koa and a way to mock JCR? I miss Livereload/Browsersync, Hot Reload. As a frontend dev, my workflow took so many steps back because of this enterprise decision.
    - Why does all the documentation tell me to "copy this component and edit it". It is so overcomplicated and convulted. I don't know if this is by design so you have to sign up for training courses, but there is no explicit directions anywhere.

I honestly feel a large enterprise could get a better custom solution from modifying Wordpress' multi-site then jumping through these hoops. I am really missing simple, static frontend development. 

If you want to learn front end HTL (or other parts of AEM), we have articles that will guide you through how to do so. For example, to learn how to build a front end HTL component ob 6.2, see the articles from this URL: http://scottsdigitalcommunity.blogspot.ca/2016/07/creating-aem-html-template-language.html?m=1. We have a video that also walks you through this use case. If you have more AEM questions, send me an email at scottm@adobe.com.

Incredible that I posted this nearly 1 1/2 years ago.

I have learned a LOT since this post. I should honestly blog more to get the information I have learned to share with the development community.

I implemented an angular app inside of AEM, it feels a bit wonky because the APP for for authors, not front end users, but needs to run in Author to update nodes in the backend. (kind of a mistake in retrosepect, but there isn't a great way to mass-edit resources with built in AEM Touch UI components)

A few things to note:

• To really get into a good developer flow, I had to take time to learn Maven and how a good AEM Maven project is setup. This really helped me learn the separation of GIT (Source Control & the Project's Code), Maven (The build tool to get local development going) and AEM.
• For FED (front-end development), your best friends inside of AEM are Sightly (HTL) and the resource resolver (Sling in some cases, straight resource resolution through data-sly-resource in others). When you start wrapping your head around everything as a resource you can begin to tackle tasks and leverage the JCR as a tool and not a pain in the arsse. Now I use sightly calls to grab me data in the JCR and treat it almost as a NO-SQL database.
• I gave brackets about 20 minutes to realize I hated it. I've always hated the clunkiness of Eclipse. I use IntelliJ myself. The only special thing going on with any of the tools is syncing/loading content from the JCR to a file system. Once I understood how .content.xml nodes are mapping to nodes in the JCR I stopped using CRX/DE for manipulating the JCR unless its quick and dirty to see stuff. Otherwise I have become a .content.xml master. There is no real good documentaiton on this, I just started noticing patterns when I was using the sync tools, which all use Vault underneath the hood. I still haven't done much with VLT as a command line tool. I did spend time to understand the vault-content-plugin that is used in the Maven projects. I don't typically sync code back and forth using VLT, unless I am downloading content that has been entered in the Author. But ultimately these are just folders and .content.xml files that I have learned to edit locally and build and push up to AEM.
• Copy and paste hell. This.. is still in full effect and I feel your pain. It's not terrible though. Once I really understood how the project on my local machine was mapping to the JCR, it sped up component development because I could copy a folder (component) change a few items in the .content.xml and have a boilerplate component to start from. Less time creating a bunch of files. I need to create a plugin that is like - Right Click -> Create AEM Component -> and it is a small wizard that asks for the fields and options I use in a typical component.
• Understanding clientlibs makes me love and hate aem. It's nice to manage them this way, but I spend a lot of time creating them for tiny snippets of code so there is only logic tied to a single component. This is great, but I miss my browserpack and other front end clientlib tools. 

Sightly's whole goal was to break concerns over Java/Front-End developers. This has, failed, in my mind. AEM is such a beast, that I feel to be productive you have to have a basic full stack understanding. Just knowing front-end isn't going to cut it because of having to understand resource resolution to really make sense of what the hell is happening in the front end. And that is more middleware then backend, i guess.

My best advice would be spending some time on some of the tools that AEM uses for project management. It was at that point I think I started using AEM to its full potential. (Sling - resource resolving, Sightly/HTL - just think of it as quirky Angular : )

Good Luck. :)

@Tyler.Maynard and @smacdonald2008 - I really do appreciate the quick responses, it's been a terribly frustrating few days for me.

I really don't think I could ever recommend AEM to anyone until:
    - there's an open-source 'light' version. I get that AEM is probably a golden goose, but it's needed so there can be a bigger community which will provide external resources and tools from novice-to-expert-level to leverage.
    - Working with AEM starts to feel more like programming/developing then learning/fighting with a propertierary system
    - Adobe does ALL devs justice and figures out a way to make AEM development text-editor/ide agnostic.
    - A simplfication of the entire system

I started writing some tasks in Node to run AEM in a docker and watches for changes with BrowserSync and pushes them via request.js.  I think I'll need to eventually write a repl that emulates crxde menus in a terminal gui (I could use request.js/phantom to scrape actual CRXDE interface) - probably won't get to a point of completing it though with the limited time I'll be using the system.

So again thank you for responding quickly, and Adobe please figure out a way to simplfy this whole process. Minimalism is divine. The path to least resistance will always overcome.

---

EDIT: It literally took me hours to figure out the bare minimum to create a component from scratch. I simply wanted to have the component group be available in the UI and also have it's component group be registered so it would show in the touch-ui's "design" mode. The bare minimum was (which wasn't documented anywhere clearly):

• cq:Component
•     cq:editConfig 
•     <component.name>.html

I'll now take the next steps on how to implement the design dialogs, but it shouldn't be a maze to figure out the requirements for displaying a component and it's group.  I like to know how things work and the requirements needed to build said things - that's why I had a huge grudge with the "copy and paste a component and edit" mentality.

--

EDIT #2:

Webdav for the win in remote mounting. Now I can stop using crxde

This happens some times, people find old threads and posts a question or comment. If you want to talk about helping community, send me an email scottm@adobe.com. There are many ways you can work with my team to help drive community content to help community members around the world.  Thxs!!