10:27:58 <cedricziel> I have to switch workplaces now
10:28:10 <cedricziel> but to answer your "unbuild" q:
10:29:04 <cedricziel> node modules _can_ consist of both js and c code, as some modules may perform costly operations which may be much much quicker when one outside of v8
10:30:04 <cedricziel> and because of that, and because node modules almost always ship with build scripts that pull in deps, perform various tasks and so on-uninstalling is called un-building
10:30:10 <cedricziel> opposed to building them on install
11:18:40 <Harpagophyt> vhs-php-fix? did i miss something?
11:22:12 <Harpagophyt> i changed the file Classes/ViewHelpers/Page/Menu/AbstractMenuViewHelper.php from https://github.com/FluidTYPO3/vhs/commit/1a9833176d2be804b1cacc6cb04f602845fd892a
13:22:48 <randomresult> i mainly work with providerextensions for FCE and PageLayouts ... this is what i build.
13:27:16 <bjo3rn> randomresult the other day I came across a tweet saying: what is bower? a dependency manager. aha, how do you install it? with npm. what is npm? a dependency manager...
13:34:20 <jlumpe> cedricziel: ah ok. it just seems weird to me, since even isaacs especially mentioned that npm is for any type of js, not just node packages
13:35:26 <cedricziel> and yes, mr schluter of course says that-but the sheer majority of packages you find on each of bower and npm are either node modules (npm) or clientside (bower)
13:35:29 <randomresult> so cedricziel what you use yeoman for ? even providerextensions?
13:36:16 <cedricziel> and why would i use a package manager like npm for clientside, if it doesnt hold all the libs i need. bower has that
13:37:00 <cedricziel> randomresult: yeoman in its heart is a too to execute generators and scaffold things, one could-but no, i dont have such generator ready
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:53:19 <jlumpe> might i ask: what were you developing?
13:53:37 <cedricziel> good thing? no. i never had a single outtage with bower as it relies on github. and when github is down.. you know. every dev takes a nap ;)
13:53:50 <cedricziel> (github==main source for bower packages)
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:58:56 <cedricziel> the app became a monster in terms of large chunks of javascript that had to interact
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
16:36:55 <Harpagophyt> https://github.com/bootstraptheme-for-typo3/fluidbootstraptheme/blob/master/Resources/Private/Templates/Content/Carousel.html this must be the problem
16:38:58 <Harpagophyt> uff, this piece of code is very buggy
17:00:59 <Harpagophyt> https://github.com/bootstraptheme-for-typo3/fluidbootstraptheme/blob/master/Resources/Private/Templates/Content/Carousel.html this must be the problem
17:44:42 <Harpagophyt> they started as enduser solution
17:44:47 <cedricziel> (not to consider the amount of budget)
17:45:12 <Denyerec> I agree Tv is easier for "end user"
17:45:12 <cedricziel> but you're right, the learning curve of fluid is steeper
17:45:19 <Harpagophyt> there is no real change to make fluid enduser friendly
17:45:26 <Denyerec> but I think the rality is, if you need to do anything complicated, you're wtiting HTML and CSS
17:45:35 <Denyerec> so the point and click of TV is perhaps... awkwardly halfway.
17:46:00 <Harpagophyt> but now you must learn, html, css, js, ts AND fluid viewhelpers
17:46:36 <Harpagophyt> with TV there was only xml and ts
17:46:47 <cedricziel> i think everyone that had to dive into basic jquery syntax (not javascript), so the basic FE developer, is able to grasp through it
17:57:23 <Denyerec> So edits would of course be lost if you had changed the files directly.
17:57:34 <Denyerec> Whether there is demand for this? Who knows.
17:57:54 <Harpagophyt> better to invest the time in the extensions self ;-)
18:00:12 <cedricziel> my 2 cents? this isnt worth it. if you want it easy, go the FLUIDTEMPLATE path. if you need typo3, you need some skills around it. sorry if this sounds to harsh.
18:00:42 <Denyerec> Exactly Harpagophyt - The learning curve isn't THAT steep
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 ?