Merge djaml about hamlpy HOT 14 CLOSED

as long as it remains possible to compile locally and only push .html to the server... many people do not like the idea of having .haml files and haml itself on production machines

from hamlpy.

Some apps, django-cms for example, don't fully compatible with djaml.

from hamlpy.

@neoascetic the idea behind merging is to bring more attention to the template loader and to finally make caching and compatibility with Django CMS

@markusgattol what would you do if people tend to edit generated files instead of hamlpy, coffescript, sass etc.?

from hamlpy.

Well, imo that's outside of the scope of any such tool. People have to know how to use them (e.g. editing .haml instead of resulting .html) and teams need to have certain conventions about how to do so.

from hamlpy.

Unfortunately I don't have a strong opinion on this right now. I'm totally heads down on attachments.me right now and it's frontend is actually a Rails app, so I'm not getting to use HamlPy in production.

Usually I prefer to keep things in smaller projects so unless there is a huge pain in using Djaml on top of HamlPy, I don't see a need to do this now. Any other thoughts?

from hamlpy.

I agree with markus, I'd much prefer to be pre-compiling hamlpy into html rather than incurring the performance penalty of using it directly in templates.

from hamlpy.

With proper caching, there will not be any penalty and you won't need to commit recompiled templates every time you change your haml templates. Most of such tools has the option to compile during startup. Why not hamlpy?

from hamlpy.

But when a page is not cached it still needs to recompile, no? Sorry, I'm not too familiar with Django's template loader system.

Is what you're asking to get rid of HamlPy and just have djaml? If there really is no performance penalty, the only downside I can see is that HamlPy can work without Django now and some people use it for other frameworks and I use it standalone when I have to use non-Python frameworks.

Also, you don't need to recompile manually, hamlpy-watcher can watch the directory and copy files automatically.

from hamlpy.

After mulling it over, I'd be interested in working on this project. I know the original developer of HamlPy is busy with other things at the moment, but I can see HamlPy falling by the wayside with the installation issues (#64) which only the original developer can fix.

Do you want to do it as a separate project or just work from the djaml project?

from hamlpy.

If there is some way to use the HamlPy code in there, please just let me know. I'm open to giving full commit access to this repo to someone actively using it.

from hamlpy.

Sorry that have been quiet during all of this. I must admit that is interesting to see people discussing something you threw together to scratch an itch. Heck, I don't even have a Django project around to play with these days (still stuck in PHP land for now and the near future).

djaml started out as an experiment to use Haml inside Django projects. It sounds like HamlPy is likely to suffer from increased bitrot without some help. They seem like a good fit.

I'm interested in helping out in this effort too. As much as my extremely basic Python + Django skills can allow.

from hamlpy.

Are people still interested in merging the two projects? Should be as simple as importing the code and updating the readme. I'll have a go at it but would like the approval of the developer (@chartjes).

from hamlpy.

I have zero objections, merge away

from hamlpy.

Whoops, forgot to tag the commits:

c56690b Add docs for template loader
3fc468e Standardise extensions and remove djaml references
fcbbc71 Merge djaml

I'll leave this issue open temporarily in case anyone encounters issues.

from hamlpy.