stopping the CQ5 linkchecker from validating a link

If you want a specific link to not be validated by the linkchecker just insert the following property into the <a> tag

 x-cq-linkchecker="skip"

Converting the multifield to use something other than text

The traditional use of the multifield is to allow users to enter a number of text fields, which are then stored all in one location in the jcr.

However the type of component that is rendered is identified by the fieldConfig property. Which defaults to a text field.

Here is a sample structure to support changing the default type to a drop down selection;

{
  "xtype": "multifield",
  "name": "./shadow",
  "fieldlabel": "stuff",
  "jcr:primaryType": "cq:Widget",
  "fieldConfig": {
    "xtype": "selection",
    "type": "select",
    "jcr:primaryType": "nt:unstructured",
    "options": {
      "jcr:primaryType": "cq:WidgetCollection",
      "o1": {
        "value": "google",
        "jcr:primaryType": "nt:unstructured",
        "text": "google"
      },
      "02": {
        "value": "yahoo",
        "jcr:primaryType": "nt:unstructured",
        "text": "yahoo"
      }
    }
  }
}

Removing a CQ lucene index

Sometimes bad things happen in CQ and the only way to correct the problem is to remove the lucene index.

• Go to ./cq-quickstart/repository
• Search for directories named index
• Move, rename, or delete, as appropriate
• restart your cq instance

bad path element "": no such file or directory

According to Google this is usually a problem that occurs when a class path is defined in a manifest file that no longer exists.

In my case, I got this compiling with maven, it occurred when I had changed a reference to a method from an instance call to a static call and failed to commit the associated change to the repository.

Modifying the landing page in Adobe CQ5

Recently got a request to modify the CQ5 landing page so only certain items appeared for authors when they logged in.

The landing page is divided into 4 sections. To change what appears we need to use the group control to set permissions on the specific nodes that are being represented on the landing page.

The right side sections are the easiest. These are defined as child nodes of the following;

/libs/cq/core/content/welcome/resources (section 2)
/libs/cq/core/content/welcome/docs (section 3)
/libs/cq/core/content/welcome/features (section 4)

Just go in and set the relevant read permissions for the group on these child nodes and voila, the page is modified.

The core list that appears on the left is a little bit trickier.

What's appearing is a list of resources that have the mixin type applied to them of cq:Console, sorted in descending order by their sling:vanityPath

To find all the items, go into crxde and perform an xpath search of
/jcr:root//*[@jcr:mixinTypes = 'cq:Console']

And following up on this, if you were to look at any of the nodes. You can easily extend your content by including the cq:Console mixin type and have this appear on your landing page.

Realized the existing jar file on the download site is extremely old. The language has changed syntax since that inception and I need to get a new one out soon

I have a second person working on the code. That's an odd experience, it's sharing something that you've been working on for so long. It's hard not to take it personal at times. Fortunately the new guy is good.

Has decent ideas and is taking it in directions I wouldn't have thought of. Which is is the whole point.

separating characters

Right now gloo&gl is taken as a unique identifier. Because all characters that are not a number or string are taken as as an "atom"

By saying, all latin numeric characters form one set while everything else combines as something different would translate that into 3 identifiers gloo, &, and gl.

Makes it easier for doing functions and writing the code in general

Possible changes

I'm considering two possible changes for posl.

1. Separating ascii and special characters into different groups. This would allow for a condensed form of writing the code
2. Including an EOL indicator - This would be huge change in the structure and format that's allowed
   

looking for help

Finally decided that I need more eyes to view the code. So I put up a "for help" sign on sourceforge

jedit plugin is now compiling and is marginally functioning. Just haven't had the time to really dive into the details yet.

Well that just sucks

I don't get much time to work on posl. Maybe an hour a week. I usually do more thinking about it and design then actual implementation.

So I took some time and wrote a shell plugin for jedit. Got it working, and my system crashed before I could get it submitted to subversion.

Lets call it a kick to the teeth :)

Scala

I used to like Scala. Never found much of a need for it and I thought some of it's concepts were a bit off. But it was exciting and it was fun to play with it for a while.

But it's user base is really starting to turn me off of it.

I see scala fanatics running around and criticizing people for not liking it, or for thinking it's too complex, or for daring to work on a competing system.

Really?

Wow.

split is complete

Got the engine split off from the rest of the "language" now it's technically possible for you to restrict the DSL down to a few specific commands. Don't want math? Don't add it. Don't want functions? That can be restricted as well. All in a jar that under 20k

Oh, I left currying in, after all. I guess I'm just weak that way.

I also got highlighting working correctly in jedit. Working on adding a plugin to provide a shell based console.

Need to work more on the error handling/display. But hell I only get an hour or two a week to work on this

posl engine

I'm really excited about the updates I've been making to posl. I'm looking to tear the existing command structure out and focus on separating the actual DSL framework with the implementation. Creating an engine so to speak. The idea here is that by splitting the two, I can focus on the "how" things will work in a clearer manner.

What I want at this point is an ability to add, with no dependencies, a simple dsl that will allow you to do whatever you want it to, as long as you provide the underlying commands.

The trick is to make it extensible enough that you could write programs in it.

I mean, what I'm doing is overkill if you simply want a command line proxy to an underlying java object. But the ability to scope, define, pass functions, that's where the fun is.

Removing currying from posl

Part of the exploration in creating a language was to see what I could do with it. To see the edges that could be obtained. So I started off rather happy that I could easily support currying from a written function point of view. And what I mean by written function. Is that for functions that were written in the language itself I could rather support it. But for those commands that were implemented in Java, well that was a tad bit more difficult.

For a while I was fine with that, but then as I refactored I realized that just how ingrained as part of the language currying needs to be. It is one of those features that doesn't necessarily get bolted on, but it is part of the definition.

So as I worked on reducing the scope of what I was doing, I realized that currying would be confusing (partially implemented) or overly cumbersome (implemented to support the java commands) and did I really need it?

I mean I had a state based mechanism so currying wasn't as clearly needed.

Well, I've gotten to the point where I need to reduce cruft. My vision for posl is refining and at this point I will be removing currying.

ANTLR

I was looking around for better ways to do my lexer. Writing a lexer by hand is/was educational and fun. But it's also a royal pain, which is the biggest reason that you have products like ANTLR in the first place.

So I pulled it down, created a grammar, and bamm I had a nice little scanner in place. The problem? The scanner itself is now 4 times the size of the rest of the application.

Is this really an issue? It depends. I was rather excited by the fact that I had created something so small and I know exactly what it's doing. The ANTLR scanner is nice and a better design. But there's a lot of magic going on there that leaves me uncomfortable.

For right now, I'm, sticking to my scanner and working on enhancing it.

An extensive example of code

function ? (predicate result1 result2) {
 if predicate {
  ! result1
 } {
  ! result2
 }
}

function <= (value1 value2) {
 if [< value1 value2] { true } {
  = value1 value2
 }
}

function incr(x) {
 + x 1
}

function decr(x) {
 - x 1
}

/*
* inclusive range
*/
function .. (begin end) {
 set func [? [<= begin end] incr decr ]
 if [= begin end] {
  append () begin
 } {
  append [.. [func begin] end] begin
 }
}

/**
 *  iterates through a list and executes 
 *  the passed in block
 */

function foreach(list block) {
    if [not [empty? list]] {
        set item [head list]
        eval block
        foreach [rest list] block
    }
}

All of the above code is needed to prepare for the following

foreach [ .. 1 12] {
    println "hi! number " item
}

The reasons why things are the way they are

One of the best things about creating a programming language is that sudden realization on why people do the things they do.

One of the most common elements you see in a language is the "end of statement" the semi-colon ';'

In posl, there's no need for one, it's one line is one statement.

That sounds alright at first (if slightly restrictive, in the form of expression it's enlarged when you see that you can include a multi-line block of code within that single line.

if [<= 2 3] {
    println "low!"
    push () 4
} {
    println "high!"
    push () 8
}

In this contrived example, the parser sees a single line which equates to

command predicate multi-line multi-line

The problem comes when you typo

if [<= 2 3] {
    println "low!"
    push () 4
 {
    println "high!"
    push () 8
}

This bad code, we forgot a right brace. However the parser isn't going to complain. It's going to assume that the brace will eventually come at some point. Currently I have an interactive parser (going to need to change that in some sort of switch mode) the interactive parser, when it runs out of code to parse, just assumes that it's going to show up at some point.

Now if we included a semi-colon

if [<= 2 3] {
    println "low!"
    push () 4
 {
    println "high!"
    push () 8
};

The parser at this point damn well knows that there's something wrong and would throw a flag.

It's not enough to change my vision but it does provide insight into why it was done in the first place.

Changes in the grammar

My original vision for posl is changing. I tried hard to look at the various constructs that compose language and provide a unique charachter set that would always mean the same thing.

That would provide us with a function definition like so

function foo|bar|{
    doSomething bar
}

The 'pipe' was used to delimit a list of atomic values that would be used as variable assignments in the context of the function.

But what was it? a list? if it was a list could I use it in other places to define a list?

Then I had braces '(' and ')' this originally defined a predicate, a boolean result. so if you saw

set x (foo bar)

you knew the result of foo bar bar would(or should) be equivalent to true.

I like this, and it makes sense at a high level. Yet underneath, it's all a list. It's conceptually the same thing, over and over again, represented in different ways.

I then ran into an issue of "lack of characters" One of the defining problems when designing a language is the sheer lack of representational characters we have on a keyboard. We've already over ridden and multi-purposed all the special characters already so you have to be cautious over what you are attempting to do.

I finally said "screw it" and removed the '|' as special characters and reverted to a list. So that the demo function in question now becomes

function foo(bar){
 doSomething
}

which, of course, makes it look closer to other languages and that, in itself, provides some value.