13:37:45 <randomresult> so you dont use it for providerextesions right now?
13:37:45 <cedricziel> i usually bootstrap a barebones provider extension and scaffold me a yeoman app inside of Documentation/Mocks
13:37:49 <jlumpe> well that is not the fault of npm, is it? Rather the fault of having two different dep-managers to begin with. I'm not against bower or anything (even though i don't use it right now), I'm just wondering
13:39:29 <jlumpe> of course, if a package isn't there, bummer.
13:39:52 <jlumpe> I just think that this "split" between npm and bower isn't necessary
13:40:16 <jlumpe> best thing might be to merge one into the other
13:40:28 <cedricziel> opposed to maven and ivy which are explicitly about encapsulating all sorts of dependencies (and are able to treat them right), we are to use those that fit our workflow best. and unless you need npm for daily operations (such as when developing node apps) i strongly advise against misusing npm for clientside libs
13:40:45 <cedricziel> bower is packageless, that's a major advantage
13:41:18 <cedricziel> even if your package is not explicitly a bower package, you can pull it in, as long as there's a valid artifact returned from the url you're telling it
13:41:24 <jlumpe> and now you've excluded all the people who actually develop client side apps by using common.js and browserify :)
13:42:23 <cedricziel> definately not and i dont see the point-browserify is another abstraction level utilized by another build tool
13:42:34 <cedricziel> i use browserify myself and if that's you path-fine
13:42:51 <cedricziel> but you dont need to be developing node apps to use browerify
13:43:07 <cedricziel> and you dont need npm packages to develop with browserify modules
13:44:20 <cedricziel> see, i insist on my point because i learned the hard way which manager works best for what package types ;) but for granted-you could do all this. I call it misusing because of the initial intentions
13:44:22 <jlumpe> This is of course just wishful thinking: but wouldn't it be nicer to just have a single manager? Just one package.json
13:49:45 <cedricziel> no offense, but i think every engineer has his own favourite set of tools for specific jobs and they vary by time and task. ask me again in a month or so. this will be a decade in terms of webdev stuff and we'll all be using hippster broccoli or at least all use OOP (which i doubt more than the broccoli thing ) :P
13:56:58 <cedricziel> i gathered the impression that node was right for the job, but it wasnt. and part of my conclusio was that the infrastructure is still immature and unusable-when you're not going to have caches in between everything
13:58:20 <cedricziel> at the time of writing, i'm using webjars for clientside libs-and as those rely on maven/ivy-i', very happy to use one tool that knows how to handle both java deps and clientside deps
13:59:29 <cedricziel> i'm too dumb for acting in such untyped environments at large scale it seems ;)
14:10:20 <Denyerec> Though they got a LOT done, and I have to say they make my job very easy
14:10:37 <Denyerec> Their english is typically excellent, makes spotting the errors tough ;)
14:11:15 <Denyerec> I had a question regarding your mock sites btw. I wondered if they include the combined CSS/JS resources, or if they reference the indiviudla components and the finished fluid template references the combined one.
14:11:37 <Denyerec> I'm concerned, because I sometimes subcontract HTML building out to people who wouldn't know their Bower from their Elbow ;)
14:12:54 <cedricziel> the Mock (in my case) references the unconcatenated resources
14:15:02 <cedricziel> the intermediate http server serves thos mocks and as artifacts i usually have one artifact that is completely built out, concated, uglified and so on, and one that is only concatenated
14:15:37 <cedricziel> i switch inclusion via a ts constant so i can have nice debugging in my dev env
14:16:08 <cedricziel> does that answer your question comprehensively?
14:42:04 <Denyerec> cedricziel - regarding the mock, yes. Regarding how the http server deals with artifacts (And what they are, in fact) is not too clear
14:42:25 <cedricziel> that's something one has to see
15:00:30 <Denyerec> cedricziel do you have anything links to such that explains what these artifacts are, or what generates them etc?
15:01:38 <Denyerec> And also what the directory structure of the mocks dir is (EG where you have your bower resources, images, css etc)
15:01:47 <cedricziel> yo webapp -> generates a scaffold
15:08:55 <Denyerec> I guess standardising that would a good move
15:09:23 <Denyerec> As randomresult was investigating though, if you're simply an integrator using a workflow to build site-template provider extensions, does this all still fit together?
15:10:29 <Denyerec> I don't like the idea of deploying via FTP, and I can't guarantee that the target server has bower, node, npm all installed, so I might be inclined to commit the compiled resources to the git repo so it can be checked out and used immediately.
15:10:50 <Denyerec> I know that will make you feel itchy, but I wonder what the alternative is, especially if the target server can't be configured with such tools.
15:11:20 <randomresult> cedricziel i managed to run yo
18:00:48 <Denyerec> Shit, if I can manage it... :D
18:08:26 <Harpagophyt> cedricziel - we all know this and except it. but there are peoples who don't use typo because of hard to learn
18:10:15 <Harpagophyt> but i will not defend something
18:21:27 <Outdoorsman> randomresult Does fluidbootstraptheme fully utilize FAL?
19:38:49 <Outdoorsman> fluidbootstraptheme does indeed use FAL after testing. I did however find that flux:field.inline.fal can't be used inside objects yet. They may need some funding... https://github.com/FluidTYPO3/flux/issues/468#issuecomment-41461016
20:24:05 <danilobuerger> Denyerec "TV remains the only solution where a complete novice could point-and-click create a working CMS" <--- hopefully those times are over… personally i think only people who actually can code should code websites… people making websites that dont know how to code just ruin the reputation of our industry..
20:24:28 <Denyerec> I was thinking the same thing as we spoke about it.
20:27:38 <danilobuerger> So the learning curve of fluid might be steep, but compared to other things a coder can and should learn, fluid and fluidtypo3 is pretty easy
20:43:27 <Outdoorsman> Hello guys... just a quick note here. I love the flexibility of your templating solutions so far, but I'm not not certain how quickly I can implement a template yet as compared to TV since I don't have a much practice yet.
20:44:29 <Outdoorsman> I LOVE flexibility, but flexibility with speed of implementation is quadruple bounus.
21:14:19 <gernot_h> hi! how can i get a content elemnt by id? with <v:render.record ?